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APPELLANT'S APPEAL BRIEF 



Sir: 



Commensurate with the Notice of Appeal filed on 16 September 201 1, 
Applicant/Appellant (herein, "Applicant") hereby submits this Appeal Brief to the Board 
of Patent Appeals and Interferences (hereinafter, the Board) under 37 C.F.R. §41 .3 1 . 
Please charge Deposit Account No. 50-1924 for the $620 appeal brief fee set forth in 37 
C.F.R. §41 .20(b)(2). This Appeal Brief is filed within two months after a notice of panel 
decision was mailed (3 November 201 1), and the undersigned representative believes that 
a one-month extension of time is due. Please charge Deposit Account No. 50-1924 for the 
$ 1 50 fee for a one-month extension of time. However, should the undersigned attorney be 
mistaken regarding the number of months (or for any other fee), please consider this a 
petition for an extension of time under 37 C.F.R. §1.1 36(a) or (b) that may be required to 
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avoid dismissal of this appeal (or as a petition for any other required fee), and debit 
Deposit Account No. 50- 1 924 as appropriate. 

(1) REAL PARTY IN INTEREST 

The real party in interest (RPI) is Nokia Corporation of Espoo, Finland, 
cited in an assignment of the U.S. application recorded on 10 October 2006 at reel 018429 
and frame 0839. 

(2) RELATED APPEALS AND INTERFERENCES 

There are no other pending appeals or interferences of which the 
undersigned representative and assignee/RPI is aware that will directly affect, be directly 
affected by or have a bearing on the Board's decision in this appeal. 

(3) STATUS OF CLAIMS 

Claims 16-28, 32-34, 36, and 38 stand rejected and are being appealed 
herein. Claims 1-15, 29-31, 35, and 37 were previously canceled. 

(4) STATUS OF AMENDMENTS 

In an after-final Response dated 4 August 201 1, the Applicant proposed a 
minor amendment to claim 38 to add a period to the end of the claim. This amendment 
was proposed subsequent to the final Office Action dated 24 May 201 1 . The Advisory 
Action dated 12 September 201 1 made no mention of the amendment. It is assumed, 
therefore, that this amendment was not entered. 

(5) SUMMARY OF CLAIMED SUBJECT MATTER 

Claim 16 is directed to a method. See, e.g., FIG. 3 and page 5, line 35 to 
page 6, line 17. The method includes checking a destination address of a received packet 
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(see block 302 of FIG. 3; page 15, line 35 to page 16, line 1) and comparing the 
destination address of the packet with at least one predetermined multicast and/or 
broadcast address (see block 303 of FIG. 3; page 16, lines 1-5). The method includes 
preventing the transmission of the packet to a first device in response to the addresses 
matching (see block 304 of FIG. 3; page 16, lines 1-17) and forwarding the packet to at 
least the first device in response to the addresses not matching (see block 305 of FIG. 3; 
page 16, lines 1-17). 

Claim 21 is directed to a system. See FIGS. 1, 2a, and 2b, and page 3, line 
30 to page 5, line 34. The system includes a first device (e.g., a mobile handheld device, 
MHD, on the left of FIG. 2a and in FIG. 1, a second device (e.g., a home network device, 
HND, on the right side of FIG. 2a and in FIG. 1), and an intermediate node (e.g., the 
interworking unit, IWU, intermediate the HND and the MHD in FIGS. 1 and 2) configured 
to arrange data transmission between the first device and the second device. At least the 
second device (e.g., HND in FIGS. 1 and 2a) is configured to multicast and/or broadcast 
packets to devices in the system. The intermediate node (e.g., IWU as shown in FIGS. 1 
and 2a) is configured to check a destination address of a packet received from the second 
device. The intermediate node is configured to compare the destination address of the 
packet with at least one predetermined multicast and/or broadcast address. The 
intermediate node is configured to prevent the transmission of the packet to the first device 
(e.g., the MHD in FIGS. 1 and 2b) in response to the addresses matching, and is 
configured to forward the packet to at least the first device (e.g., the MHD in FIGS. 1 and 
2b) in response to the addresses not matching. See also, e.g., page 5, line 35 to page 6, 
line 17. 
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Claim 22 is directed to an apparatus. See, e.g., FIG. 2b and page 5, lines 
14-34. The apparatus includes a processor (e.g., CPU in FIG. 2b) configured to check a 
destination address of a received packet; compare the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; prevent the 
transmission of the packet to a first device in response to the addresses matching; and 
forward the packet to at least the first device in response to the addresses not matching. 
See also, e.g., page 5, line 35 to page 6, line 17. 

Claim 32 is directed to a memory. See, e.g., MEM in FIG. 2b, and page 5, 
lines 14-34. The memory stores a computer program (see, e.g., the IWM, interworking 
means, and page 5, lines 14-34). The computer program is configured to control a 
processor (e.g., CPU shown in FIG. 2b) to perform the following: check a destination 
address of a received packet; comparing the destination address of the packet with at least 
one predetermined multicast and/or broadcast address; preventing transmission of the 
packet in the system to a first device in response to the addresses matching; and 
forwarding the packet to at least the first device in response to the addresses not matching. 
See also, e.g., page 5, line 35 to page 6, line 17. 

(6) GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

A. The first grounds for rejection presented for review by the Board is whether claims 
16-18, 21-25, 28, 32, 34, and 38 are patentable under 35 U.S.C. § 103(a) over Rune (U.S. 
Patent Publication no. 2004/0167988) in view of Jou, U.S. Patent Publication no. 
2005/0036489. 

B. The second grounds for rejection presented for review by the Board is whether 
claims 19, 20, 26, 27, and 33 are patentable under 35 U.S.C. § 103(a) over Rune in view of 
Vasisht, U.S. Patent Publication no. 2004/0133689. 
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C. The third grounds for rejection presented for review by the Board is whether claim 
36 is patentable under 35 U.S.C. § 103(a) over Rune in further view of Tung, U.S. Patent 
Publication no. 2006/0136562. 

(7) ARGUMENT 

A. First grounds for rejection 

Claims 16-18, 21-25, 28, 32, 34, and 38 stand rejected under 35 U.S.C. 
U.S.C. § 103(a) as being obvious over Rune in view of Jou. Applicant respectfully 
disagrees. The currently pending independent claims are claims 16, 21, 22, and 32. 

1. Claims 16, 17 

The Examiner rejected claim 16 under 103(a) being unpatentable over 
Rune in view of Jou. Applicant respectfully disagrees. 

Claim 16 is reproduced below. 
A method comprising: 

checking a destination address of a received packet; 

comparing the destination address of the packet with at least 
one predetermined multicast and/or broadcast address; 

preventing the transmission of the packet to a first device in 
response to the addresses matching; and 

forwarding the packet to at least the first device in response 
to the addresses not matching. 

The Examiner states the following: 

However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 
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Outstanding Office Action, page 3. Therefore, the Examiner admits that Rune does not 
disclose at least the subject matter of comparing the destination address of the packet with 
at least one predetermined multicast and/or broadcast address and preventing the 
transmission of the packet to a first device in response to the addresses matching. 

The Examiner then points to Jou for alleged disclosure of this subject 
matter. However, Jou does not disclose this subject matter for at least the following 
reasons. 

a) Jou does not disclose the subject matter alleged by the Examiner 
(and therefore the combination of Rune and Jou does not disclose 
this subject matter): First Reason 

The instant application has a priority date of 6 February 2004 under, e.g., 
M.P.E.P. §201.13, 35 U.S.C. §119 and 37 C.F.R. §1.55. That is, the priority date of 6 
February 2004 is based on a Finnish application filed on that date, which later became an 
international (P.C.T.) application filed on 4 February 2005. The international application 
entered national stage in the United States on 10 October 2006 as the instant application. 
A proper claim for priority was made at least in the Declaration filed on 10 October 2006. 
In fact, the U.S. Patent Publication no. 2007/0127394 of the instant application lists 
"Foreign Application Priority Data" as "Feb. 6, 2004", as shown by the following portion 
of the first page of this publication: 
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(i2? Patent Application Publication n<» Pub. No.: US 2007/0127394 Al 

Siirbu et al. (43) Pub. Date: Jun. 7, 2007 
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(30) Foreign Application Priority Data 
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Publication Chmiiicalioo 



(51) InfcCL 
11941 1248 

(52) UACL 



(2006.01) 
(2006.01) 



(57) 



ABSTRACT 



. 370/254: 370/589 



The invention relates to a method of arranging communi* 
cation in a local area networking, system comprising 3 first 
device, a second device and an wterraedbk node tor arrang- 
ing data tramyni&ston between die first device and die second 
device. The second device is arranged to multicast and/or 
broadcast message* to devices in the system. The transmis- 
sion of multicast and/or broadcast messages to the first 
device is prevented by the intcrworking means. 



Therefore, the priority date of the instant invention is 6 February 2004. 



Turning to Jou, the published application 2005/0036489 was filed on 10 
August 2004, after the priority date of 6 February 2004 of the instant application. Jou's 
published application claims priority from provisional application 60/495,186, a copy of 
which is enclosed herein in section (9), "Evidence Appendix". This copy was also 
submitted in the after-final amendment dated 4 August 201 1 (as Appendix A). The Jou 
provisional application was filed on 15 August 2003. Therefore, for material to be cited 
under 35 U.S.C. §102 (and therefore §103) against the instant application, that material 
must exist prior to the priority date of the instant application of 6 February 2004. 



The Examiner cites to paragraph 29 of Jou's published application, which 
states the following: 



[0029] FIG. 5 illustrates the processing flow chart on 
receiving a broadcast frame. In step 500, a wireless transport device 
receives a broadcast frame. The wireless transport device will determine 
whether or not the DA filed is the same as the local MAC address of this 
device (510). If positive, the wireless transport device drops the frame 
because it is an echoed frame (step 530). Otherwise, it uses Auxiliary 
Address to verify whether this frame is received through the correct 
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neighbor, namely in step 520, to look up the route table. Subsequently, in 
step 540, the wireless transport device determines whether the TA address 
is the neighboring node the frame should come from. If positive, then the 
wireless transport device relays the frame or performs other process (550), 
otherwise, drops the frame (step 530). 

The Examiner relies on this section of Jou's published application in order to assert that 
Jou's published application discloses the subject matter of "comparing the destination 
address of the packet with at least one predetermined multicast and/or broadcast address": 

response to the address not matching. However, Jou teaches comparing the destination 
address of the packet with at least one predetermined multicast and/or broadcast address; 
preventing, the transmission of the packet to a first device in response to the addresses 
matching; in response to the address not matching [see paragraph 0029 where a 
wireless transport device (intermediate node) receives a broadcast frame; the 
wireless transport device determines whether or not the Destination Address field is 
the same as the local MAC address (predetermined multicast address) of this device; 
if positive (in response the addresses matching), the wireless transport device drops 
the frame). It would have been obvious for a person having ordinary skill in the art to 

Final Office Action, dated 24 May 201 1. That is, the Examiner is relying on the statement 
'The wireless transport device will determine whether or not the DA [destination address] 
filed (sic - should be "field") is the same as the local MAC address of this device (510)" 
in paragraph 29 of Jou's published application in order for Jou's published application to 
disclose the subject matter in the instant claims of "comparing the destination address of 
the packet with at least one predetermined multicast and/or broadcast address". 

However, the subject matter regarding using a destination address field 
(e.g., for containing a previous hop address) does not appear in Jou's provisional 
application . This subject matter regarding a destination address field therefore has the 
filing date (10 August 2004) of Jou's published application (and not the earlier filing date 
of Jou's provisional application). The filing date (10 August 2004) of Jou's published 
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application is after the priority date (6 February 2006) of the instant application, and 
therefore the cited subject matter regarding a destination address field in paragraph 29 of 
Jou's published application does not qualify as prior art under 35 U.S.C. §102. 

Consequently, the sections cited by the Examiner of Jou's published 
application cannot be cited as prior art against the claims of the instant application. 
Because the Examiner admits that Rune does not disclose certain subject matter from the 
claims, and some of that certain subject matter supposedly disclosed in Jou's published 
application is not prior art against the independent claims, then the combination of Rune 
and Jou does not disclose this certain subject matter. Applicant respectfully submits the 
§ 103(a) rejections against the independent claims must fail. 

Applicant made similar arguments in the after-final Amendment dated 4 
August 201 1. In response, the Examiner in the Advisory Action dated 12 September 201 1 
stated the following: 

In response to appficartfs argument that trie Jou reference Is not valid because the provisional application does not contain the cited 
paragraph (see applicants remarks page 9*10) , it should bo noted that Jou's provisional application stiff have support for said paragraph 
(See second paragraph on tier 'summary of the invention' in page 3 where Jou teaches "When N1 and «2 relay the frame, they ooih add X 
in the -previous hop" Raid of the frame. Most likely device X win receive both these relayed frames from N1 and IM2. With its address 
contained in the frame, device X can immediately realize (compare and determine) it should drop the frames without processing"} 

Advisory Action dated 12 September 201 1, page 2. What Jou's provisional application 
states is the following: 
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4. The method for a transport device when relays a broadcast frame, to add the 
address information of the previous hop from where the frame comes into the 
transmitted frame. 

5. The method according to claim 4 f wherein: 

When a wireless transport device receives a broadcast frame whose "previous 
hop** field contains its own address, the device can drop the frame without any 
further processing. 

For example* a device X cither sends or relays a broadcast frame to its neighbors 
Nl and N2. When Nl and N2 relay the frame, they both add X in the "previous 
hop'* field of the frame. Most likely device X will receive both these relayed 
frames from Nl and N2. With its address contained in the frame, device X can 
immediately realized it should drop the frames without processing. 



Jou's provisional application, page 1. See also: 

To filter out echo frames, broadcast frames have to carry the address information of 
previous hop in the transmitted frame so once the previous hop receives the frames, it can 
ignore these echo frames without further processing. For example, a device X either 
sends or relays a broadcast frame to its neighbors Nl and N2. When Nl and N2 relay the 
frame, they both add X in the "previous hop" field of the frame Most likely device X 
will receive both these relayed frames from Nl and N2. With its address contained in the 
frame, device X can immediately realize it should drop the frames without processing. 

Jou's provisional application, page 3. 

Regardless, Jou's provisional application does not state or imply that the 
"previous hop" field is a destination address field (in fact, Applicant cannot find the term 
"destination address" used anywhere in Jou's provisional application). This is important 
because the Examiner is using Jou to allegedly disclose the subject matter of "comparing 
the destination address of the packet with at least one predetermined multicast and/or 
broadcast address". Jou's provisional application simply does not disclose anything 
related to a destination address field or its use. Furthermore, the "previous hop" field 
disclosed in Jou's provisional application certainly does not contain a "destination 
address", as this field contains instead "address information of the previous hop from 
where the frame comes". See page 1, claim 4 (and claim 5) of Jou's provisional 
application. 
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As stated above, the subject matter regarding using a destination 
address field (e.g., for containing a previous hop address) does not appear in J oil's 
provisional application . This subject matter regarding the destination address field 
therefore has the filing date (10 August 2004) of Jou's published application (and not the 
earlier filing date of Jou's provisional application). The filing date (10 August 2004) of 
Jou's published application is after the priority date (6 February 2006) of the instant 
application, and therefore the cited subject matter regarding the destination address field in 
paragraph 29 of Jou's published application does not qualify as prior art under 35 U.S.C. 
§102. Because the Examiner admits that Rune does not disclose certain subject matter 
from the claims, and some of that certain subject matter supposedly disclosed in Jou's 
published application is not prior art against the independent claims, then the combination 
of Rune and Jou does not disclose this certain subject matter. Applicant respectfully 
submits the § 103(a) rejections against the independent claims must fail. 

b) Jou does not disclose the subject matter alleged by the Examiner 
(and therefore the combination of Rune and Jou does not disclose 
this subject matter): Second Reason 

Even if the cited sections of Jou's published application are prior art against 
the instant independent claims, Applicant respectfully submits that Jou's published 
application does not disclose the subject matter the Examiner asserts is disclosed by Jou's 
published application. For instance, the Examiner cites to paragraph 29 of Jou's published 
application (emphasis added): 

[0029] FIG. 5 illustrates the processing flow chart on 
receiving a broadcast frame. In step 500, a wireless transport device 
receives a broadcast frame. The wireless transport device will determine 
whether or not the DA filed (sic - should be "field") is the same as the 
local MAC address of this device (510) . If positive, the wireless transport 
device drops the frame because it is an echoed frame (step 530). 
Otherwise, it uses Auxiliary Address to verify whether this frame is 
received through the correct neighbor, namely in step 520, to look up the 
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route table. Subsequently, in step 540, the wireless transport device 
determines whether the TA address is the neighboring node the frame 
should come from. If positive, then the wireless transport device relays the 
frame or performs other process (550), otherwise, drops the frame (step 
530). 

This section of Jou's published application indicates that a determination is made of 
whether or not the DA (destination address) field is the same as the local MAC (media 
access control) address of the device. It is known in the art that a MAC address is a unique 
identifier assigned to network interfaces for communications on the physical network 
segment. What the sentence "If positive, the wireless transport device drops the frame 
because it is an echoed frame (step 530)" appears to mean is that the current device 
previously transmitted the frame, and the frame is being echoed back to the device. Thus, 
the device put the MAC address of itself into the DA field of the frame, and transmitted 
the frame. When the device receives a frame that has its MAC address, the device then 
determines the frame is an echoed frame and can be ignored. See also paragraph 22 of 
Jou's published application (emphasis added): 

[0022] Depending on the method in unicast routing path 
calculation, the forwarding table for unicast frames can be used as the table 
that is used to look up the incoming neighboring device for a broadcast 
frame originator (i.e. FIG. 2). In this case, there is no extra effort in 
generating the broadcast frame reduction table. The other method to reduce 
the resource spending on broadcast frames is to reduce the processing effort 
for echoed broadcast frames. For example, a device X either sends or relays 
a broadcast frame to its neighbors Nl and N2. When Nl and N2 relay the 
frame, most likely device X will receive both the frames. Using the method 
mentioned earlier can cause the frames being dropped eventually. However, 
a table lookup for each frame will be needed for device X. To relieve the 
processing load, Nl and N2 can both add the address of X inside the frame. 
When X receives a broadcast frame, it can check whether the frame is 
echoed from itself. If so, the frame can be dropped immediately without 
processing. Therefore, to filter out echo frames, broadcast frames have 
to carry the address information of previous hop in the transmitted 
frame. This can be achieved by using an unused field in the 802. 1 1 MAC 
header. In broadcasting, the Address 3 (DA, destination address) of FIG. 3 
is not used. The "previous hop" information is carried in the location the 
Address 3 (DA, destination address). 
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Moreover, the MAC address of the device is not a "broadcast address", as 
the MAC address is the address of the device itself: "The wireless transport device will 
determine whether or not the DA filed (sic - should be "field") is the same as the local 
MAC address of this device (510)." Paragraph 29 of Jou's published application. See 
also paragraph 22 of Jou's published application: "Therefore, to filter out echo frames, 
broadcast frames have to carry the address information of [the] previous hop in the 
transmitted frame." Another device receiving the frame with the MAC address of the 
previous hop is not going to determine the MAC address is a broadcast address or use the 
MAC address as a broadcast address. This means that the MAC address of a device will 
not be the same as the broadcast address. The same is true for a multicast address: a 
multicast address will not be the same as a MAC address. This is true because, by 
definition, the multicast address is to be used for communication with multiple 
addresses/devices, while a MAC address is made to be specific to a single device. 

To put this a different way, any device receiving a packet with a destination 
address that is the same as a MAC address of one of the devices on a network should 
forward the packet toward the device having that MAC address. However, there is only 
one device in the network with that MAC address. Therefore, the MAC address is not a 
broadcast address (a packet addressed with a broadcast address is destined for every 
device in the network) or is not a multicast address (a packet addressed with a multicast 
address is destined for at least two devices in the network). 

In the Advisory Action dated 12 September 201 1, the Examiner states the 

following: 

'multicast/broadcast and destination address). The recitations broadcast/multicast address and multicast address are not defined by trie 
claim; the specification does not provide a clear explanation of said terms. In the absence of an express intent to impart a novel meaning to 
the daim terms, the words are presumed to take on the ordinary and customary meanings attributed to them by those of ordinary skill in the 
art [MPEP 2 1 1 1.01 J. In this case Jou's destination address (although MAC address of the previous hop) is considered a multicast address 
since it is a multicast destination address (as shown above and discussed in paragraph 0022-Jou). Applicant's arguments do not show how 
the claims prevent a reasonable broadest interpretation of said terms would prevent such interpretation as supported by the Jou reference. 
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Advisory Action dated 12 September 201 1, page 2. 

One skilled in the art knows what the terms "MAC address", "multicast 
address", and "broadcast address" are. See, e.g., 
http://en.wikipedia.org/wiki/MAC_address ("MAC address"), 
http://en.wikipedia.org/wiki/Multicast_address ("multicast address"), and 
http://en.wikipedia.org/wiki/Broadcast_address ("broadcast address"). In fact, it is known 
that a broadcast address in MAC (e.g., 802.1 1) is all ones, e.g., FFFFFFFF for 32 bits in 
hexadecimal. See paragraph 27 of Jou: "a broadcast frame in WITnet is a WDS frame 
with Receiver Address Field (please refer to FIG. 3) being, for instant (sic), Oxffffffffffff \ 
See also http://en.wikipedia.org/wiki/MAC_address: "Packets sent to the broadcast 
address, all one bits, are received by all stations on a local area network. In hexadecimal 
the broadcast address would be FF:FF:FF:FF:FF:FF". Jou is using the broadcast address 
of Oxffffffffffff consistently with what is known in the art for one particular network and 
protocol. 

Additionally, even the term "destination address" is respectfully being read 
by the Examiner in a manner not consistent with the way one skilled in the art would read 
the term. Applicant's claim recites (in general) comparing the destination address of the 
packet with at least one multicast and/or broadcast address. In Jou's published 
application, a value in a destination address field is compared with a MAC address of the 
device receiving the packet. (See paragraph 29 of Jou's published application.) What is in 
the destination address field is not a "destination address" as this term is commonly used 
in the art. Instead, it is the MAC address of the previous hop. See the last sentence of 
paragraph 22 and paragraph 29 of Jou's published application. In fact, the actual 
"destination address" of the packet in Jou's published application appears to be in the 
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Receiver Address Field and has a value of Oxffffffffffff. See paragraph 27 of Jou. Thus, 
even the term "destination address" is being read by the Examiner in a way that is not the 
way one skilled in the art would read this term. 

Therefore, Applicant respectfully submits that it is the Examiner who is 
interpreting the terms "multicast address" and "broadcast address" in a way that is not in 
accord with the way these terms would be interpreted by one skilled in the art. That is, 
one skilled in the art would not interpret MAC, broadcast, and multicast addresses in the 
way the Examiner is interpreting these terms in order to get Jou to read on the instant 
independent claims. 

Thus, for at least the above reasons, Jou's published application does not 
disclose at least the subject matter of "comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address", as recited in claim 16 
and generally in the other independent claims. 

Because the Examiner admits that Rune does not disclose the subject matter 
in the claims of "comparing the destination address of the packet with at least one 
predetermined multicast and/or broadcast address", and because Jou's published 
application does not disclose this certain subject matter, the combination of Rune and Jou 
does not disclose this subject matter. Applicant respectfully submits the 103(a) rejections 
against the independent claims must fail. 

c) The combination of Rune and Jou 

The Applicant has stated above that the combination of Rune and Jou does 
not disclose all features of the independent claims, including claim 16. For instance, the 
Examiner states the following: 
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However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 



Outstanding Office Action, page 3. Therefore, the Examiner admits that Rune does not 
disclose this subject matter. The Applicant shows above that Jou's published application 
either is not valid prior art against the instant claims or does not teach or imply this subject 
matter. Therefore, the combination of Rune and Jou does not teach or imply this subject 
matter. 



Nonetheless, the Examiner states the following in the Advisory Action 
dated 12 September 2011: 



Examiner respectfuSy disagrees with applicants assertion that Rune does not teach "comparing the destinatino address of the packet with 
the at least one predetermined multicast andfor broadcast addess" and "preventing the transmission of the packet to a first device in 
reports© to the address* matching" (see appBcanfs remarks pages 13-16) . This assertion amounts to attacking the reference tdMduaBy. 
The office action relied upon the Jou reference for teaching "comparing the destinatirto address of the packet with the at least one 
predetermined multicast and/or broadcast addess" (specially the step of 'comparing*, 'destination address* and 'multicast address' are 
disclosed by the Jou reference), tn response to applicant's arguments against the references individually, one cannot show nonoovtousness 
by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 
USPQ 871 (CCPA 1981); tn re Merck & Co., 800 F.2d 1091. 231 USPQ 375 (Fed. Cir. 1986). In addition, examiner respectfully disagrees 
with applicant's statements that seem to imply that filtering is done (only?) by filtering out packets by type and not address, in contrast, even 
though Rune teaches filtering out by type. Rune atso teaches filtering out by address (see paragraph 0215). Therefore, one having ordinary 
skill in the art would take Rune (for teaching filtering out broadcast packets by address, and use Jou to loam how to fitter by address (ie, 
comparing the destination address of the packet with multicast address). 



Applicant respectfully submits that Applicant has stated multiple times that the 
combination of Rune and Jou does not disclosed the features of the independent claims, as 
the Examiner admits that Rune does not disclose this subject matter and the Applicant 
shows above that Jou's published application either is not valid prior art against the instant 
claims or does not teach or imply this subject matter. If the Examiner admits that Rune 
does not disclose certain subject matter and Applicant shows that some or all of that 
subject matter is not disclosed or implied by Jou, then the combination of Rune and Jou 
cannot disclose or imply that subject matter. 
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For sake of argument, however, Applicant will now show that even though 
the Examiner has admitted that Rune does not disclose "comparing the destination address 
of the packet with at least one predetermined multicast and/or broadcast address", and 
"preventing the transmission of the packet to a first device in response to the addresses 
matching", Applicant will now show the same. 

Applicant cannot find in Rune where a comparison is performed between a 
multicast and/or broadcast address and a destination address of a packet in order to prevent 
transmission of the packet or forward the packet. 

There are a number of indications that can include multicast addresses in 
Rune. See, e.g., paragraphs 156, 173, 186, and 187 of Rune. However, nowhere in these 
paragraphs (or any other paragraphs) of Rune can Applicant find a comparison that is 
performed between a multicast address and a destination address of a packet in order to 
prevent transmission of the packet or forward the packet. 

Regarding broadcast addresses, Rune makes specific reference to these 
addresses in paragraphs 215 and 291, neither of which involves a comparison using a 
destination address and a broadcast address. 

Rune does discuss packet filtering. See paragraphs 195-218 of Rune. If 
this packet filtering is in any way related to a comparison that is performed between a 
multicast and/or broadcast address and a destination address of a packet in order to prevent 
transmission of the packet or forward the packet, Applicant cannot find in Rune where that 
is the case. In fact, Rune states the following (emphasis added): 

[0197] The NAL packet type filtering in the NAP is 
performed in the packet type filtering function 912, which is present only 
on the scatternet side of the NAP. The NAL packet type filtering, in some 
embodiments of the invention, is very simple: all NAPSA broadcast type 
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and scatternet broadcast type packets are passed by the packet type 
filtering function 912 to the NAP-IPH . while all other packet types are 
passed to the address filtering function 914. 

This section of Rune appears to teach away from comparing a broadcast address and a 
destination address, as all broadcast type packets are simply forwarded. 

In paragraph 215, Rune states the following (emphasis added): 

[0215] For broadcast ARP replies received from the LAN, 
the address filtering process is much more complicated. The address 
filtering function first extracts the "target MAC address" from the ARP 
reply. This is the MAC address of the intended receiver of the ARP reply. 
In other words, this is the MAC address of the node that sent the ARP 
request (or possibly the ARP-route-request) that triggered the ARP reply. 
The target MAC address is extracted even though the destination 
address of the packet is a broadcast address. The target MAC address 
is then made subject to the same check as a destination address of a 
unicast packet. If the target MAC address was not found in the address 
table or if it was found in the address table and the address table indicated 
that the corresponding node is located on the scatternet side of the NAP, the 
packet is passed to the NAP-B. The address filtering function then has 
an option to convert the broadcast ARP reply into a unicast ARP reply 
by replacing the broadcast address with the target MAC address in the 
destination address field. The purpose of this option is to save resources 
(mainly bandwidth) in the scatternet. 

None of the highlighted (or any other portion) of this cited text indicates in any way that a 
comparison is performed between a multicast and/or broadcast address and a destination 
address of a packet in order to prevent transmission of the packet or forward the packet. 

What Rune states regarding broadcast types is the following (emphasis 

added) 



[0123] FIGS. 10-15 illustrate the coverage areas of the 
different broadcast types. The NAPSA broadcast type, as the name implies, 
is used to broadcast packets to a single NAPSA. This is illustrated in FIG. 
10 (which is similar to FIG. 8), where each isolated gray area 1000-1008 
represents a different NAPSA broadcast area. A NAPSA broadcast packet 
is not allowed to leave its broadcast area. Thus, NAPSA broadcast 
packets are not forwarded to the LAN and are not allowed to cross a 
NAPSA border. 
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[0124] The scatternet broadcast type, as the name implies, is 
used to broadcast packets within the scatternet. This arrangement is 
illustrated in FIG. 1 1, where each contiguous gray area 1 100-1 106 
represents different broadcast areas for a scatternet broadcast packet. Such 
broadcast packets are not forwarded to the LAN, When more than one 
AD exists in a scatternet, the scatternet broadcast packets carrying higher 
layer protocol packets, i.e. packets from protocol layers above the NAL, 
e.g. IP, are not allowed to cross an AD border. These packets are 
consequently limited to a part of the scatternet belonging to the same AD. 
Scatternet broadcast packets that are not carrying packets from higher layer 
protocols, such as NAL control packets, however, are allowed to cross AD 
borders and may therefore still be broadcast in the whole scatternet. A NAL 
control packet does not encapsulate data from a higher protocol layer and is 
only used to transfer signaling and control information between NAL 
entities in different Bluetooth nodes. This arrangement is illustrated in FIG. 
12, where each contiguous gray area 1200 and 1202 represents the 
broadcast area of an NAL control packet. 

[0125] The AD broadcast type covers the LAN and any 
attached scatternets that are associated with the same AD as the LAN. 
These broadcast packets are forwarded by NAPs from/to the LAN to/from 
the scatternet, but the NAPSA borders in the scatternet are respected. This 
arrangement is illustrated in FIG. 13, where each contiguous gray area 
1 300- 1 304 represents the broadcast area of an AD broadcast packet. An 
AD broadcast packet is used to reach all the nodes in the AD (including the 
nodes on the LAN). All broadcast packets that are forwarded from the LAN 
to the scatternet are sent using the AD broadcast type. 

[0126] The scatternet- AD broadcast type is a special 
broadcast type used only for route requests. This broadcast type is, as the 
name implies, a combination of the scatternet broadcast type and the AD 
broadcast type. The scatternet- AD broadcast packets are distributed through 
the entire scatternet without respecting the NAPSA borders, as well as the 
entire AD via the NAPs. However, the NAPSA borders are respected after 
a scatternet- AD broadcast packet re-enters the scatternet via a NAP. 

Thus, in Rune, the NAPSA broadcast packets are not forward to a scatternet, and the 
scatternet broadcast packets are not forwarded to the LAN. However, these packets are 
not forwarded based on their broadcast type, which is defined by an indicator in a NAL 
(network adaptive layer) header (emphasis added): 

[0122] In addition to the routing protocol discussed above, 
the NAL also has a broadcast mechanism. (Note that broadcasting on the 
LAN is inherent in the shared medium and no "broadcast" mechanism is 
needed.) In accordance with embodiments of the invention, the NAL 
includes four different types of broadcasts: NAPSA broadcast, scatternet 
broadcast, AD broadcast, and scatternet- AD broadcast. The differences 
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between broadcast types lie in the scope of the distribution and how the 
NAPs and other nodes at the NAPSA borders treat the different broadcast 
packets. Note that the broadcast type is defined by an indicator in the 
NAL header. In that sense, these different broadcast types can only exist in 
the scatternet. On the other hand, an Ethernet broadcast packet (originated 
on the LAN) that is forwarded from the LAN to the scatternet becomes an 
AD broadcast packet when it is forwarded into the scatternet. The broadcast 
type may be indicated in the NAL header, for example, with a two-bit 
indicator, as indicated in Table 2. 

Thus, the broadcast type is defined in Rune by an indicator in the NAL header. 

It is clear that filtering of broadcast packets in Rune is performed without 
examination of destination addresses for packets (emphasis added): 

[0196] The second main component of the invention is the 
packet filtering mechanism. As already mentioned, a NAP does not 
indiscriminately forward packets. Instead, it uses the packet filtering 
mechanisms (see FIG. 9) to reduce the number of unnecessarily forwarded 
packets. For example, forwarding is unnecessary when both the source and 
the destination node are located on the same side of the NAP. Furthermore, 
NAL broadcast packets of the NAPSA broadcast type and the scatternet 
broadcast type are always blocked by the packet filtering mechanisms. 
Only those packets that pass the packet filtering mechanisms are 
forwarded to the scatternet. The generated useless traffic is a waste of 
resources, especially so in the scatternet where radio resources and 
processing resources are scarce. Furthermore, this could lead to the 
scatternet being flooded by traffic from the LAN with its shared medium 
and much higher capacity. Therefore, a packet filtering mechanism is 
needed in order to limit the forwarding of unnecessary traffic. The packet 
filtering is based on the destination address and the NAL packet type. 
Filtering may also be based on higher layer protocols. 

[0197] The NAL packet type filtering in the NAP is 
performed in the packet type filtering function 912, which is present only 
on the scatternet side of the NAP. The NAL packet type filtering , in some 
embodiments of the invention, is very simple: all NAPSA broadcast type 
and scatternet broadcast type packets are passed by the packet type 
filtering function 912 to the NAP-IPH. while all other packet types are 
passed to the address filtering function 914, 

Thus, packets having the NAPSA broadcast and scatternet broadcast types are filtered, and 
all other packet types are passed to an address filtering function, for forwarding to the 
correct address. See also, e.g., paragraphs [0222], [0224], [0237] of Rune. 
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As is noted in paragraphs [0125] and [0197] from Rune above, packets 
having the AD broadcast type are forwarded, as are packets having the scatternet-AD 
broadcast type (see paragraphs [0126] and [0197]). 

Regarding multicast addresses, these appear to be related to route entries. 
See, e.g., the following: 

[0173] When (and if) the NAP-B of a NAP receives an 
encapsulated non-ARP-route-request (via the NAP-PFL), the NAP 
processes the non-ARP-route-request just like any node would process a 
received non-ARP-route-request. Thus, the NAP forwards the non-ARP- 
route-request into the scatternet, unless it already has a route to the 
destination node, or unless the NAP itself is the destination node. In the 
latter case, the NAP can immediately return an encapsulated non-ARP- 
route-reply. Then the next hop node in the route entry for the source node is 
indicated as "another NAP." This indication may be just a general 
indication, or it may be a specific indication that includes a NAP multicast 
address or the specific source MAC address of the Ethernet packet that 
carried the received encapsulated ARP-route-request. The choice between 
general indication, NAP multicast address or source MAC address depends 
on whether broadcast packets, multicast packets or unicast packets are used 
to carry a corresponding encapsulated ARP-route-reply. 

See also paragraphs [0156], [0186], and [0187] of Rune. There are 
additional references to "multicast" in Rune, but none of these references relate to 
comparing a multicast and/or broadcast address and a destination address of a packet in 
order to prevent transmission of the packet or forward the packet. 

Applicant can find nowhere in Rune of disclosure or implication of a 
comparison that is performed between a multicast and/or broadcast address and a 
destination address of a packet in order to prevent transmission of the packet or forward 
the packet, as recited generally in the independent claims. Applicant has already shown 
above that Jou's published application either is not valid prior art against the instant claims 
or does not teach or imply this subject matter. Therefore, the combination of Rune and 
Jou does not teach or imply this subject matter. 
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For at least these reasons, the § 103(a) rejections against claim 16 should be 

withdrawn. 

2. Claims 18, 25 

Claim 18 recites "A method as claimed in claim 16, wherein the destination 
address is an internet protocol address." Applicant has shown above that Applicant can 
find nowhere in Rune of disclosure or implication of a comparison that is performed 
between a multicast and/or broadcast address and a destination address of a packet in order 
to prevent transmission of the packet or forward the packet, as recited generally in the 
independent claims. Applicant has already shown above that Jou's published application 
either is not valid prior art against the instant claims or does not teach or imply this subject 
matter. Therefore, the combination of Rune and Jou does not teach or imply this subject 
matter. 



Thus, claim 18 is patentable for at least these reasons. However, the 
Examiner points to paragraph 210 of Rune. This paragraph and the following paragraph 
state the following: 

[0210] As for ARP-route-requests, encapsulated ARP-route- 
requests, and ARP requests received by the address filtering function on 
either side of the NAP, if such a packet is addressed to the NAP itself, i.e., 
if its "target IP address" is the NAP's own IP address, the address filtering 
function passes the packet to the NAP-IPH. Otherwise, since such a packet 
does not contain a destination MAC address, the address filtering function 
in the NAP cannot use its address table in the way described above to find 
out on which side of the NAP the destination node is located. The 
destination MAC address of the Ethernet packet in which an encapsulated 
ARP-route-request is encapsulated does not apply in this situation, since 
that address is not the address of the destination node of the ARP-route- 
request. However, each of the ARP-route-request, encapsulated ARP-route- 
request, and ARP request contains a "target IP address," i.e., the IP address 
of the destination node. Thus, the address filtering function can utilize the 
ARP cache to find the MAC address of the destination node, provided that 
the target IP address is stored in the ARP cache. Once the destination MAC 
address is retrieved, the condition for passing the packet to the NAP-B is 
the same as described above for general unicast packets and unicast ARP 
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replies, i.e., the packet will be passed to the NAP-B, unless the address 
table indicates that the destination node is located on the side of the NAP 
where the packet was received. 

[021 1] If the destination MAC address cannot be retrieved, 
the address filtering function has no indication of where the destination 
node is located. In that case, it will simply pass the packet to the NAP-B. 

What this section of Rune appears to indicate is that it is the MAC address that is used at 

least for filtering. By contrast, in claim 18 (in combination with claim 16), the destination 

address is an internet protocol address that is used for comparison purposes and for 

preventing the transmission of the packet or forwarding the packet. Therefore, the 

Examiner has not met a burden of creating a prima facie § 103(a) argument that the 

combination of Rune and Jou discloses that the destination address (used for comparison 

purposes and for preventing the transmission of the packet or forwarding the packet) is an 

internet protocol address, and the § 103(a) rejections against claim 18 should be 



withdrawn. 



3. Claim 21 

The Examiner rejected claim 21 under 103(a) being unpatentable over 
Rune in view of Jou. Applicant respectfully disagrees. 

Claim 21 is reproduced below. 

A system comprising: 

a first device; 

a second device; and 

an intermediate node configured to arrange data 
transmission between the first device and the second device; 

wherein at least the second device is configured to multicast 
and/or broadcast packets to devices in the system, wherein the intermediate 
node is configured to check a destination address of a packet received from 
the second device, the intermediate node is configured to compare the 
destination address of the packet with at least one predetermined multicast 
and/or broadcast address, and wherein the intermediate node is configured 
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to prevent the transmission of the packet to the first device in response to 
the addresses matching, and wherein the intermediate node is configured to 
forward the packet to at least the first device in response to the addresses 
not matching. 

The Examiner states the following: 

However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 

Outstanding Office Action, page 3. Therefore, the Examiner admits that Rune does not 
disclose at least the subject matter of the intermediate node is configured to compare the 
destination address of the packet with at least one predetermined multicast and/or 
broadcast address, and wherein the intermediate node is configured to prevent the 
transmission of the packet to the first device in response to the addresses matching. 

The Examiner then points to Jou for alleged disclosure of this subject 
matter. However, Jou does not disclose this subject matter for at least the following 
reasons. 

a) Jou does not disclose the subject matter alleged by the Examiner 
(and therefore the combination of Rune and Jou does not disclose this 
subject matter): First Reason 

The instant application has a priority date of 6 February 2004 under, e.g., 
M.P.E.P. §201.13, 35 U.S.C. §1 19 and 37 C.F.R. §1.55. That is, the priority date of 6 
February 2004 is based on a Finnish application filed on that date, which later became an 
international (P.C.T.) application filed on 4 February 2005. The international application 
entered national stage in the United States on 10 October 2006 as the instant application. 
A proper claim for priority was made at least in the Declaration filed on 10 October 2006. 
In fact, the U.S. Patent Publication no. 2007/0127394 of the instant application lists 
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"Foreign Application Priority Data" as "Feb. 6, 2004", as shown by the following portion 
of the first page of this publication: 
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ABSTRACT 
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'Hit? invention relate* to a method of arranging communi- 
cation in a local mra networking syslcra comprising a firs! 
device, u second device and an intermediate node for arrang- 
ing data traitsiuisiittm between die fi/st device and the second 
device. The second device is arranged to. multicast and/or 
broadcast message* to devices in the system. The transmis- 
sion of multicast andVor broadcast messages to the first 
device is prevented by the interworking means. 



Therefore, the priority date of the instant invention is 6 February 2004. 

Turning to Jou, the published application 2005/0036489 was filed on 10 
August 2004, after the priority date of 6 February 2004 of the instant application. Jou's 
published application claims priority from provisional application 60/495,186, a copy of 
which is enclosed herein in section (9), "Evidence Appendix". This copy was also 
submitted in the after-final amendment dated 4 August 201 1 (as Appendix A). The Jou 
provisional application was filed on 15 August 2003. Therefore, for material to be cited 
under 35 U.S.C. §102 (and therefore §103) against the instant application, that material 
must exist prior to the priority date of the instant application of 6 February 2004. 

The Examiner cites to paragraph 29 of Jou's published application, which 
states the following: 



[0029] FIG. 5 illustrates the processing flow chart on 
receiving a broadcast frame. In step 500, a wireless transport device 
receives a broadcast frame. The wireless transport device will determine 
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whether or not the DA filed is the same as the local MAC address of this 
device (510). If positive, the wireless transport device drops the frame 
because it is an echoed frame (step 530). Otherwise, it uses Auxiliary 
Address to verify whether this frame is received through the correct 
neighbor, namely in step 520, to look up the route table. Subsequently, in 
step 540, the wireless transport device determines whether the TA address 
is the neighboring node the frame should come from. If positive, then the 
wireless transport device relays the frame or performs other process (550), 
otherwise, drops the frame (step 530). 

The Examiner relies on this section of Jou's published application in order to assert that 
Jou's published application discloses the subject matter of "compare the destination 
address of the packet with at least one predetermined multicast and/or broadcast address": 

response to the address not matching. However, iou teaches comparing the destination 
address of the packet with at least one predetermined multicast and/or broadcast address; 
preventing, the transmission of the packet to a first device in response to the addresses 
matching; in response to the address not matching (see paragraph 0029 where a 
wireless transport device (intermediate node) receives a broadcast frame; the 
wireless transport device determines whether or not the Destination Address field is 
the same as the local MAC address (predetermined multicast address) of this device: 
if positive (in response the addresses matching)* the wireless transport device drops 
the frame] . It would have been obvious for a person having ordinary skill in the art to 

Final Office Action, dated 24 May 201 1. That is, the Examiner is relying on the statement 
"The wireless transport device will determine whether or not the DA [destination address] 
filed (sic - should be "field") is the same as the local MAC address of this device (510)" 
in paragraph 29 of Jou's published application in order for Jou's published application to 
disclose the subject matter in the instant claims of "comparing the destination address of 
the packet with at least one predetermined multicast and/or broadcast address". 

However, the sub ject matter regarding using a destination address field 
(e.g.. for containing a previous hop address) does not appear in Jou's provisional 
application . This subject matter regarding a destination address field therefore has the 
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filing date (10 August 2004) of Jou's published application (and not the earlier filing date 
of Jou's provisional application). The filing date (10 August 2004) of Jou's published 
application is after the priority date (6 February 2006) of the instant application, and 
therefore the cited subject matter regarding a destination address field in paragraph 29 of 
Jou's published application does not qualify as prior art under 35 U.S.C. §102. 

Consequently, the sections cited by the Examiner of Jou's published 
application cannot be cited as prior art against the claims of the instant application. 
Because the Examiner admits that Rune does not disclose certain subject matter from the 
claims, and some of that certain subject matter supposedly disclosed in Jou's published 
application is not prior art against the independent claims, then the combination of Rune 
and Jou does not disclose this certain subject matter. Applicant respectfully submits the 
§ 103(a) rejections against the independent claims must fail. 

Applicant made similar arguments in the after-final Amendment dated 4 
August 201 1 . In response, the Examiner in the Advisory Action dated 12 September 201 1 
stated the following: 

In response to appficent's argument that trie Jou reference is not valid because the provisional application does not contain trio cited 
paragraph ($ee applicants remarks page 9-10) , it should be noted that Jou's provisional application strD have support for said paragraph 
(See second paragraph under 'summary of the invention* in page 3 where Jou teaches •When Nt end N2 relay the frame, they both add X 
In the "previous hop" field of the frame. Most likely device X will receive both these relayed frames from N1 and N2. With its address 
contained in the frame, device X can immediately realize (compare end determine) it should drop the frames without processing'') 

Advisory Action dated 12 September 201 1, page 2. What Jou's provisional application 
states is the following: 
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4. The method for a transport device when relays a broadcast frame, to add the 
address information of the previous hop from where the frame comes into the 
transmitted frame. 

5. The method according to claim 4, wherein: 

When a wireless transport device receives a broadcast frame whose "previous 
hop** field contains its own address, the device can drop the frame without any 
further processing. 

For example, a device X either sends or relays a broadcast frame to its neighbors 
Nl and K2. When Ml and N2 relay the frame, they both add X in the "previous 
hop'* field of the frame. Most likely device X will receive both these relayed 
frames from Nl and N2. With its address contained in the frame, device X can 
immediately realized it should drop the frames without processing. 



Jou's provisional application, page 1. See also: 

To filter out echo frames, broadcast frames have to carry the address information of 
previous hop in the transmitted frame so once the previous hop receives the frames, it can 
ignore these echo frames without further processing. For example, a device X either 
sends or relays a broadcast frame to its neighbors Nl and N2. When Nl and N2 relay the 
frame, they both add X in the "previous hop" field of the frame. Most likely device X 
will receive both these relayed frames from N I and N2. With its address contained in the 
frame, device X can immediately realize it should drop the frames without processing. 

Jou's provisional application, page 3. 

Regardless, Jou's provisional application does not state or imply that the 
"previous hop" field is a destination address field (in fact, Applicant cannot find the term 
"destination address" used anywhere in Jou's provisional application). This is important 
because the Examiner is using Jou to allegedly disclose the subject matter of "comparing 
the destination address of the packet with at least one predetermined multicast and/or 
broadcast address". Jou's provisional application simply does not disclose anything 
related to a destination address field or its use. Furthermore, the "previous hop" field 
disclosed in Jou's provisional application certainly does not contain a "destination 
address", as this field contains instead "address information of the previous hop from 
where the frame comes". See page 1, claim 4 (and claim 5) of Jou's provisional 
application. 
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As stated above, the subject matter regarding using a destination 
address field (e.g,. for containing a previous hop address) does not appear in Jou's 
provisional application . This subject matter regarding the destination address field 
therefore has the filing date (10 August 2004) of Jou's published application (and not the 
earlier filing date of Jou's provisional application). The filing date (10 August 2004) of 
Jou's published application is after the priority date (6 February 2006) of the instant 
application, and therefore the cited subject matter regarding the destination address field in 
paragraph 29 of Jou's published application does not qualify as prior art under 35 U.S.C. 
§102. Because the Examiner admits that Rune does not disclose certain subject matter 
from the claims, and some of that certain subject matter supposedly disclosed in Jou's 
published application is not prior art against the independent claims, then the combination 
of Rune and Jou does not disclose this certain subject matter. Applicant respectfully 
submits the § 103(a) rejections against the independent claims must fail. 

b) Jou does not disclose the subject matter alleged by the Examiner 
(and therefore the combination of Rune and Jou does not disclose this 
subject matter): Second Reason 

Even if the cited sections of Jou's published application are prior art against 
the instant independent claims, Applicant respectfully submits that Jou's published 
application does not disclose the subject matter the Examiner asserts is disclosed by Jou's 
published application. For instance, the Examiner cites to paragraph 29 of Jou's published 
application (emphasis added): 

[0029] FIG. 5 illustrates the processing flow chart on 
receiving a broadcast frame. In step 500, a wireless transport device 
receives a broadcast frame. The wireless transport device will determine 
whether or not the DA filed (sic - should be "field") is the same as the 
local MAC address of this device (510) . // positive, the wireless transport 
device drops the frame because it is an echoed frame (step 530). 
Otherwise, it uses Auxiliary Address to verify whether this frame is 
received through the correct neighbor, namely in step 520, to look up the 
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route table. Subsequently, in step 540, the wireless transport device 
determines whether the TA address is the neighboring node the frame 
should come from. If positive, then the wireless transport device relays the 
frame or performs other process (550), otherwise, drops the frame (step 
530). 

This section of Jou's published application indicates that a determination is made of 
whether or not the DA (destination address) is the same as the local MAC (media access 
control) address of the device. It is known in the art that a MAC address is a unique 
identifier assigned to network interfaces for communications on the physical network 
segment. What the sentence "If positive, the wireless transport device drops the frame 
because it is an echoed frame (step 530)" appears to mean is that the current device 
previously transmitted the frame, and the frame is being echoed back to the device. Thus, 
the device put the MAC address of itself into the frame, and transmitted the frame. When 
the device receives a frame that has its MAC address, the device then determines the 
frame is an echoed frame and can be ignored. See also paragraph 22 of Jou's published 
application (emphasis added): 

[0022] Depending on the method in unicast routing path 
calculation, the forwarding table for unicast frames can be used as the table 
that is used to look up the incoming neighboring device for a broadcast 
frame originator (i.e. FIG. 2). In this case, there is no extra effort in 
generating the broadcast frame reduction table. The other method to reduce 
the resource spending on broadcast frames is to reduce the processing effort 
for echoed broadcast frames. For example, a device X either sends or relays 
a broadcast frame to its neighbors Nl and N2. When Nl and N2 relay the 
frame, most likely device X will receive both the frames. Using the method 
mentioned earlier can cause the frames being dropped eventually. However, 
a table lookup for each frame will be needed for device X. To relieve the 
processing load, Nl and N2 can both add the address of X inside the frame. 
When X receives a broadcast frame, it can check whether the frame is 
echoed from itself. If so, the frame can be dropped immediately without 
processing. Therefore, to filter out echo frames, broadcast frames have 
to carry the address information of previous hop in the transmitted 
frame. This can be achieved by using an unused field in the 802. 1 1 MAC 
header. In broadcasting, the Address 3 (DA, destination address) of FIG. 3 
is not used. The "previous hop" information is carried in the location the 
Address 3 (DA, destination address). 
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Moreover, the MAC address of the device is not a "broadcast address", as 
the MAC address is the address of the device itself: "The wireless transport device will 
determine whether or not the DA filed (sic - should be "fields is the same as the local 
MAC address of this device (510)." Paragraph 29 of Jou's published application. See 
also paragraph 22 of Jou's published application: 'Therefore, to filter out echo frames, 
broadcast frames have to carry the address information of [the] previous hop in the 
transmitted frame." Another device receiving the frame with the MAC address of the 
previous hop is not going to determine the MAC address is a broadcast address or use the 
MAC address as a broadcast address. This means that the MAC address of a device will 
not be the same as the broadcast address. The same is true for a multicast address: a 
multicast address will not be the same as a MAC address. This is true because, by 
definition, the multicast address is to be used for communication with multiple 
addresses/devices, while a MAC address is made to be specific to a single device. 

To put this a different way, any device receiving a packet with a destination 
address that is the same as a MAC address of one of the devices on a network should 
forward the packet toward the device having that MAC address. However, there is only 
one device in the network with that MAC address. Therefore, the MAC address is not a 
broadcast address (a packet addressed with a broadcast address is destined for every 
device in the network) or is not a multicast address (a packet addressed with a multicast 
address is destined for at least two devices in the network). 

In the Advisory Action dated 12 September 201 1, the Examiner states the 

following: 

'multicast/broadcast and destination address). The recitations broad cast/multicast address and multicast address are not defined by the 
claim; the specification does not provide a dear explanation of said terms. In the absence of an express intent to impart a novel meaning to 
the claim terms, the words are presumed to take on the ordinary and customary meanings attributed to them by those of ordinary skill in the 
art IMPEP 211 1,01 J. In this case Jou's destination address (although MAC address of the previous hop) is considered a multicast address 
since it is a multicast destination address (as shown above and discussed in paragraph 0022-Jou). Applicant's arguments do not show how 
the claims prevent a reasonable broadest interpretation of said terms would prevent such interpretation as supported by the Jou reference. 
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Advisory Action dated 12 September 201 1, page 2. 

One skilled in the art knows what the terms "MAC address", "multicast 
address", and "broadcast address" are. See, e.g., 
http://en.wikipedia.org/wiki/MAC_address ("MAC address"), 
http://en.wikipedia.org/wiki/Multicast_address ("multicast address"), and 
http://en.wikipedia.org/wiki/Broadcast_address ("broadcast address"). In fact, it is known 
that a broadcast address in MAC (e.g., 802.1 1) is all ones, e.g., FFFFFFFF for 32 bits in 
hexadecimal. See paragraph 27 of Jou ("a broadcast frame in WITnet is a WDS frame 
with Receiver Address Field (please refer to FIG. 3) being, for instant (sic), 
Oxffffffffffff '), or http://en.wikipedia.org/wiki/MAC_address ("Packets sent to the 
broadcast address, all one bits, are received by all stations on a local area network. In 
hexadecimal the broadcast address would be FF:FF:FF:FF:FF:FF'). Jou is using the 
broadcast address of Oxffffffffffff consistently with what is known in the art for one 
particular network and protocol. 

Additionally, even the term "destination address" is respectfully being read 
by the Examiner in a manner not consistent with the way one skilled in the art would read 
the term. Applicant's claim recites (in general) comparing the destination address of the 
packet with at least one multicast and/or broadcast address. In Jou's published 
application, a value in a destination address field is compared with a MAC address of the 
device receiving the packet. (See paragraph 29 of Jou's published application.) What is in 
the destination address field is not a "destination address" as this term is commonly used 
in the art. Instead, it is the MAC address of the previous hop. See the last sentence of 
paragraph 22 and paragraph 29 of Jou's published application. In fact, the actual 
"destination address" of the packet in Jou's published application appears to be in the 
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Receiver Address Field and has a value of Oxffffffffffff. See paragraph 27 of Jou. Thus, 
even the term "destination address" is being read by the Examiner in a way that is not the 
way one skilled in the art would read this term. 

Therefore, Applicant respectfully submits that it is the Examiner who is 
interpreting the terms "multicast address" and "broadcast address" in a way that is not in 
accord with the way these terms would be interpreted by one skilled in the art. That is, 
one skilled in the art would not interpret MAC, broadcast, and multicast addresses in the 
way the Examiner is interpreting these terms in order to get Jou to read on the instant 
independent claims. 

Thus, for at least the above reasons, Jou's published application does not 
disclose at least the subject matter of "compare the destination address of the packet with 
at least one predetermined multicast and/or broadcast address", as recited in claim 21 and 
generally in the other independent claims. 

Because the Examiner admits that Rune does not disclose the subject matter 
in the claims of "compare the destination address of the packet with at least one 
predetermined multicast and/or broadcast address", and because Jou's published 
application does not disclose this certain subject matter, the combination of Rune and Jou 
does not disclose this subject matter. Applicant respectfully submits the 103(a) rejections 
against the independent claims must fail. 

c) The combination of Rune and Jou 

The Applicant has stated above that the combination of Rune and Jou does 
not disclose all features of the independent claims, including claim 21. For instance, the 
Examiner states the following: 
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However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 



Outstanding Office Action, page 3. Therefore, the Examiner admits that Rune does not 
disclose this subject matter. The Applicant shows above that Jou's published application 
either is not valid prior art against the instant claims or does not teach or imply this subject 
matter. Therefore, the combination of Rune and Jou does not teach or imply this subject 
matter. 



Nonetheless, the Examiner states the following in the Advisory Action 
dated 12 September 201 1: 



Examiner respectfully disagrees with applicant's assertion that Rune does not teach 'comparing the destinatino address of the packet with 
the at least one predetermined multicast end/or broadcast addess" and "preventing the transmission of the packet to a first device in 
reponse to the address* matching" (see app Seam's remarks pages 13-16). This assertion amounts to attacking the reference tcVtduafly. 
The office action relied upon the Jou reference for teaching "comparing the destinatino address of the packet with the at least one 
predetermined multicast and/or broadcast addess* (specialty the step of 'comparing', 'destination address' and 'multicast address' are 
disclosed by the Jou reference), in response to applicants arguments against the references individually, one cannot show nonooviousness 
by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 
USPQ 871 (CCPA 1981); In re Merck & Co., 800 F,2d 1091. 231 USPQ 375 (Fed. Cir. 1936). In addition, examiner respectfutty disagrees 
with applicant's statements that seem to Imply that filtering Is done (only?) by filtering out packets by type and not address, in contrast, even 
though Rune teaches filtering out by type, Rune also teaches filtering out by address (see paragraph 0215). Therefore, one having ordinary 
skill in the art would take Rune (for teaching fi Caring out broadcast packets by address, and use Jou to loam how to filter by address (ie. 
comparing the destination address of the packet with multicast address). 



Applicant respectfully submits that Applicant has stated multiple times that the 
combination of Rune and Jou does not disclosed the features of the independent claims, as 
the Examiner admits that Rune does not disclose this subject matter and the Applicant 
shows above that Jou's published application either is not valid prior art against the instant 
claims or does not teach or imply this subject matter. If the Examiner admits that Rune 
does not disclose certain subject matter and Applicant shows that some or all of that 
subject matter is not disclosed or implied by Jou, then the combination of Rune and Jou 
cannot disclose or imply that subject matter. 
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For sake of argument, however, Applicant will now show that even though 
the Examiner has admitted that Rune does not disclose "compare the destination address 
of the packet with at least one predetermined multicast and/or broadcast address", and 
"prevent the transmission of the packet to a first device in response to the addresses 
matching", Applicant will now show the same. 

Applicant cannot find in Rune where a comparison is performed between a 
multicast and/or broadcast address and a destination address of a packet in order to prevent 
transmission of the packet or forward the packet. 

There are a number of indications that can include multicast addresses in 
Rune. See, e.g., paragraphs 156, 173, 186, and 187 of Rune. However, nowhere in these 
paragraphs (or any other paragraphs) of Rune can Applicant find a comparison that is 
performed between a multicast address and a destination address of a packet in order to 
prevent transmission of the packet or forward the packet. 

Regarding broadcast addresses, Rune makes specific reference to these 
addresses in paragraphs 215 and 291, neither of which involves a comparison using a 
destination address and a broadcast address. 

Rune does discuss packet filtering. See paragraphs 195-218 of Rune. If 
this packet filtering is in any way related to a comparison that is performed between a 
multicast and/or broadcast address and a destination address of a packet in order to prevent 
transmission of the packet or forward the packet, Applicant cannot find in Rune where that 
is the case. In fact, Rune states the following (emphasis added): 

[0197] The NAL packet type filtering in the NAP is 
performed in the packet type filtering function 912, which is present only 
on the scatternet side of the NAP. The NAL packet type filtering, in some 
embodiments of the invention, is very simple: all NAPSA broadcast type 
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and scatternet broadcast type packets are passed by the packet type 
ffltering function 912 to the NAP-IPH . while all other packet types are 
passed to the address filtering function 914. 

This section of Rune appears to teach away from comparing a broadcast address and a 
destination address, as all broadcast type packets are simply forwarded. 

In paragraph 215, Rune states the following (emphasis added): 

[0215] For broadcast ARP replies received from the LAN, 
the address filtering process is much more complicated. The address 
filtering function first extracts the "target MAC address" from the ARP 
reply. This is the MAC address of the intended receiver of the ARP reply. 
In other words, this is the MAC address of the node that sent the ARP 
request (or possibly the ARP-route-request) that triggered the ARP reply. 
The target MAC address is extracted even though the destination 
address of the packet is a broadcast address. The target MAC address 
is then made sub ject to the same check as a destination address of a 
unicast packet. If the target MAC address was not found in the address 
table or if it was found in the address table and the address table indicated 
that the corresponding node is located on the scatternet side of the NAP, the 
packet is passed to the NAP-B. The address filtering function then has 
an option to convert the broadcast ARP reply into a unicast ARP reply 
by replacing the broadcast address with the target MAC address in the 
destination address field. The purpose of this option is to save resources 
(mainly bandwidth) in the scatternet. 

None of the highlighted (or any other portion) of this cited text indicates in any way that a 
comparison is performed between a multicast and/or broadcast address and a destination 
address of a packet in order to prevent transmission of the packet or forward the packet. 

What Rune states regarding broadcast types is the following (emphasis 

added) 

[0123] FIGS. 10-15 illustrate the coverage areas of the 
different broadcast types. The NAPSA broadcast type, as the name implies, 
is used to broadcast packets to a single NAPSA. This is illustrated in FIG. 
10 (which is similar to FIG. 8), where each isolated gray area 1000-1008 
represents a different NAPSA broadcast area. A NAPSA broadcast packet 
is not allowed to leave its broadcast area. Thus, NAPSA broadcast 
packets are not forwarded to the LAN and are not allowed to cross a 
NAPSA border. 
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[0124] The scatternet broadcast type, as the name implies, is 
used to broadcast packets within the scatternet. This arrangement is 
illustrated in FIG. 11, where each contiguous gray area 1 100-1 106 
represents different broadcast areas for a scatternet broadcast packet. Such 
broadcast packets are not forwarded to the LAN. When more than one 
AD exists in a scatternet, the scatternet broadcast packets carrying higher 
layer protocol packets, i.e. packets from protocol layers above the NAL, 
e.g. IP, are not allowed to cross an AD border. These packets are 
consequently limited to a part of the scatternet belonging to the same AD. 
Scatternet broadcast packets that are not carrying packets from higher layer 
protocols, such as NAL control packets, however, are allowed to cross AD 
borders and may therefore still be broadcast in the whole scatternet. A NAL 
control packet does not encapsulate data from a higher protocol layer and is 
only used to transfer signaling and control information between NAL 
entities in different Bluetooth nodes. This arrangement is illustrated in FIG. 
12, where each contiguous gray area 1200 and 1202 represents the 
broadcast area of an NAL control packet. 

[0125] The AD broadcast type covers the LAN and any 
attached scatternets that are associated with the same AD as the LAN. 
These broadcast packets are forwarded by NAPs from/to the LAN to/from 
the scatternet, but the NAPSA borders in the scatternet are respected. This 
arrangement is illustrated in FIG. 13, where each contiguous gray area 
1300-1304 represents the broadcast area of an AD broadcast packet. An 
AD broadcast packet is used to reach all the nodes in the AD (including the 
nodes on the LAN). All broadcast packets that are forwarded from the LAN 
to the scatternet are sent using the AD broadcast type. 

[0126] The scatternet- AD broadcast type is a special 
broadcast type used only for route requests. This broadcast type is, as the 
name implies, a combination of the scatternet broadcast type and the AD 
broadcast type. The scatternet-AD broadcast packets are distributed through 
the entire scatternet without respecting the NAPSA borders, as well as the 
entire AD via the NAPs. However, the NAPSA borders are respected after 
a scatternet- AD broadcast packet re-enters the scatternet via a NAP. 

Thus, in Rune, the NAPSA broadcast packets are not forward to a scatternet, and the 
scatternet broadcast packets are not forwarded to the LAN. However, these packets are 
not forwarded based on their broadcast type, which is defined by an indicator in a NAL 
(network adaptive layer) header (emphasis added): 

[0122] In addition to the routing protocol discussed above, 
the NAL also has a broadcast mechanism. (Note that broadcasting on the 
LAN is inherent in the shared medium and no "broadcast" mechanism is 
needed.) In accordance with embodiments of the invention, the NAL 
includes four different types of broadcasts: NAPSA broadcast, scatternet 
broadcast, AD broadcast, and scatternet- AD broadcast. The differences 
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between broadcast types lie in the scope of the distribution and how the 
NAPs and other nodes at the NAPSA borders treat the different broadcast 
packets. Note that the broadcast type is defined by an indicator in the 
NAL header. In that sense, these different broadcast types can only exist in 
the scatternet. On the other hand, an Ethernet broadcast packet (originated 
on the LAN) that is forwarded from the LAN to the scatternet becomes an 
AD broadcast packet when it is forwarded into the scatternet. The broadcast 
type may be indicated in the NAL header, for example, with a two-bit 
indicator, as indicated in Table 2. 

Thus, the broadcast type is defined in Rune by an indicator in the NAL header. 

It is clear that filtering of broadcast packets in Rune is performed without 
examination of destination addresses for packets (emphasis added): 

[0196] The second main component of the invention is the 
packet filtering mechanism. As already mentioned, a NAP does not 
indiscriminately forward packets. Instead, it uses the packet filtering 
mechanisms (see FIG. 9) to reduce the number of unnecessarily forwarded 
packets. For example, forwarding is unnecessary when both the source and 
the destination node are located on the same side of the NAP. Furthermore, 
NAL broadcast packets of the NAPSA broadcast type and the scatternet 
broadcast type are always blocked by the packet filtering mechanisms. 
Only those packets that pass the packet filtering mechanisms are 
forwarded to the scatternet The generated useless traffic is a waste of 
resources, especially so in the scatternet where radio resources and 
processing resources are scarce. Furthermore, this could lead to the 
scatternet being flooded by traffic from the LAN with its shared medium 
and much higher capacity. Therefore, a packet filtering mechanism is 
needed in order to limit die forwarding of unnecessary traffic. The packet 
filtering is based on the destination address and the NAL packet type. 
Filtering may also be based on higher layer protocols. 

[0197] The NAL packet type filtering in the NAP is 
performed in the packet type filtering function 912, which is present only 
on the scatternet side of the NAP. The NAL packet type filtering , in some 
embodiments of the invention, is very simple: all NAPSA broadcast type 
and scatternet broadcast type packets are passed by the packet type 
filtering function 912 to the NAP-IPH, while all other packet types are 
passed to the address filtering function 914. 

Thus, packets having the NAPSA broadcast and scatternet broadcast types are filtered, and 
all other packet types are passed to an address filtering function, for forwarding to the 
correct address. See also, e.g., paragraphs [0222], [0224], [0237] of Rune. 



38 



AppL No. 10/587,979 

Corresponding to Notice of Appeal Hied 16 September 201 1 

As is noted in paragraphs [0125] and [0197] from Rune above, packets 
having the AD broadcast type are forwarded, as are packets having the scatternet-AD 
broadcast type (see paragraphs [0126] and [0197]). 

Regarding multicast addresses, these appear to be related to route entries. 
See, e.g., the following: 

[0173] When (and if) the NAP-B of a NAP receives an 
encapsulated non-ARP-route-request (via the NAP-PFL), the NAP 
processes the non-ARP-route-request just like any node would process a 
received non-ARP-route-request. Thus, the NAP forwards the non-ARP- 
route-request into the scatternet, unless it already has a route to the 
destination node, or unless the NAP itself is the destination node. In the 
latter case, the NAP can immediately return an encapsulated non-ARP- 
route-reply. Then the next hop node in the route entry for the source node is 
indicated as "another NAP." This indication may be just a general 
indication, or it may be a specific indication that includes a NAP multicast 
address or the specific source MAC address of the Ethernet packet that 
carried the received encapsulated ARP-route-request. The choice between 
general indication, NAP multicast address or source MAC address depends 
on whether broadcast packets, multicast packets or unicast packets are used 
to carry a corresponding encapsulated ARP-route-reply. 

See also paragraphs [0156], [0186], and [0187] of Rune. There are 
additional references to "multicast" in Rune, but none of these references relate to 
comparing a multicast and/or broadcast address and a destination address of a packet in 
order to prevent transmission of the packet or forward the packet. 

Applicant can find nowhere in Rune of disclosure or implication of a 
comparison that is performed between a multicast and/or broadcast address and a 
destination address of a packet in order to prevent transmission of the packet or forward 
the packet, as recited generally in the independent claims. Applicant has already shown 
above that Jou's published application either is not valid prior art against the instant claims 
or does not teach or imply this subject matter. Therefore, the combination of Rune and 
Jou does not teach or imply this subject matter. 
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For at least these reasons, the § 103(a) rejections against claim 21 should be 

withdrawn. 

4. Claims 22, 23, 24, 28 

The Examiner rejected claim 22 under 103(a) being unpatentable over 
Rune in view of Jou. Applicant respectfully disagrees. 

Claim 22 is reproduced below. 

An apparatus comprising: 
a processor configured to 

check a destination address of a received packet, ; 

compare the destination address of the packet with at least 
one predetermined multicast and/or broadcast address; 

prevent the transmission of the packet to a first device in 
response to the addresses matching; and 

forward the packet to at least the first device in response to 
the addresses not matching. 

The Examiner states the following: 

However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 

Outstanding Office Action, page 3. Therefore, the Examiner admits that Rune does not 
disclose at least the subject matter of comparing the destination address of the packet with 
at least one predetermined multicast and/or broadcast address and preventing the 
transmission of the packet to a first device in response to the addresses matching. 
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The Examiner then points to Jou for alleged disclosure of this subject 
matter. However, Jou does not disclose this subject matter for at least the following 
reasons. 



a) Jou does not disclose the subject matter alleged by the Examiner 
(and therefore the combination of Rune and Jou does not disclose this 
subject matter): First Reason 

The instant application has a priority date of 6 February 2004 under, e.g., 
M.P.EJP. §201.13, 35 U.S.C. §119 and 37 C.F.R. §1.55. That is, the priority date of 6 
February 2004 is based on a Finnish application filed on that date, which later became an 
international (P.C.T.) application filed on 4 February 2005. The international application 
entered national stage in the United States on 10 October 2006 as the instant application. 
A proper claim for priority was made at least in the Declaration filed on 10 October 2006. 
In fact, the U.S. Patent Publication no. 2007/0127394 of the instant application lists 
"Foreign Application Priority Data" as "Feb. 6, 2004", as shown by the following portion 
of the first page of this publication: 

09) United States 

(i2) Patent Application Publication ( io) Pub. No.: US 2007/0127394 Al 

Srirbu et aL (43) Pub. Dare: Jun. 7, 2007 
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The invention relates to a nuahod of arranging conununi- 
calktn in a local area networking system comprising d first 
device- a .second device and an intermediate node for arrang- 
ing data mi iismLssion between the first device and the second 
device. The second device is arranged to multicast and/or 
broadcast messageii to devices in the system. The transmis- 
sion of multicast andA»r broadcast messages to (be first 
device is prevented by the interworking means. 



Therefore, the priority date of the instant invention is 6 February 2004. 
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Turning to Jou, the published application 2005/0036489 was filed on 10 
August 2004, after the priority date of 6 February 2004 of the instant application. Jou's 
published application claims priority from provisional application 60/495,186, a copy of 
which is enclosed herein in section (9), "Evidence Appendix". This copy was also 
submitted in the after-final amendment dated 4 August 201 1 (as Appendix A). The Jou 
provisional application was filed on 15 August 2003. Therefore, for material to be cited 
under 35 U.S.C. §102 (and therefore §103) against the instant application, that material 
must exist prior to the priority date of the instant application of 6 February 2004. 

The Examiner cites to paragraph 29 of Jou's published application, which 
states the following: 

[0029] FIG. 5 illustrates the processing flow chart on 
receiving a broadcast frame. In step 500, a wireless transport device 
receives a broadcast frame. The wireless transport device will determine 
whether or not the DA filed is the same as the local MAC address of this 
device (510). If positive, the wireless transport device drops the frame 
because it is an echoed frame (step 530). Otherwise, it uses Auxiliary 
Address to verify whether this frame is received through the correct 
neighbor, namely in step 520, to look up the route table. Subsequently, in 
step 540, the wireless transport device determines whether the TA address 
is the neighboring node the frame should come from. If positive, then the 
wireless transport device relays the frame or performs other process (550), 
otherwise, drops the frame (step 530). 

The Examiner relies on this section of Jou's published application in order to assert that 
Jou's published application discloses the subject matter of "comparing the destination 
address of the packet with at least one predetermined multicast and/or broadcast address": 
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response to the address not matching. However, Jou teaches comparing the destination 
address of the packet with at least one predetermined multicast and/or broadcast address; 
preventing, the transmission of the packet to a first device in response to the addresses 
matching; in response to the address not matching (see paragraph 0029 where a 
wireless transport device (intermediate node) receives a broadcast frame; the 
wireless transport device determines whether or not the Destination Address field is 
the same as the local MAC address (predetermined multicast address) of this device; 
if positive (in response the addresses matching), the wireless transport device drops 
the frame]. It would have been obvious for a person having ordinary skill in the art to 

Final Office Action, dated 24 May 201 1 . That is, the Examiner is relying on the statement 
"The wireless transport device will determine whether or not the DA [destination address] 
filed (sic - should be "field") is the same as the local MAC address of this device (510)" 
in paragraph 29 of Jou's published application in order for Jou's published application to 
disclose the subject matter in the instant claims of "comparing the destination address of 
the packet with at least one predetermined multicast and/or broadcast address". 

However, the subject matter regarding using a destination address field 
(e.g., for containing a previous hop address) does not appear in Jou's provisional 
application . This subject matter regarding a destination address field therefore has the 
filing date (10 August 2004) of Jou's published application (and not the earlier filing date 
of Jou's provisional application). The filing date (10 August 2004) of Jou's published 
application is after the priority date (6 February 2006) of the instant application, and 
therefore the cited subject matter regarding a destination address field in paragraph 29 of 
Jou's published application does not qualify as prior art under 35 U.S.C. §102. 

Consequently, the sections cited by the Examiner of Jou's published 
application cannot be cited as prior art against the claims of the instant application. 
Because the Examiner admits that Rune does not disclose certain subject matter from the 
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claims, and some of that certain subject matter supposedly disclosed in Jou's published 
application is not prior art against the independent claims, then the combination of Rune 
and Jou does not disclose this certain subject matter. Applicant respectfully submits the 
§ 103(a) rejections against the independent claims must fail. 

Applicant made similar arguments in the after-final Amendment dated 4 
August 201 1 . In response, the Examiner in the Advisory Action dated 12 September 201 1 
stated the following: 

In response to appicanfs argument that me Jou reference is not valid because the provisional appScation does not contain the cited 
paragraph (see applicant's remarks page 9-10) , it should be noted that Jou's provisional application strfl have support for said paragraph 
(See second paragraph under 'summary of the invention* in page 3 where Jou teaches "When N1 and N2 relay the frame, they both add X 
In the "previous hop" field of the frame. Most likely device X will receive both these relayed frames from N1 and N2. With its address 
contained in the frame, device X can immediately realize (compare and determine) it should drop the frames without processing"} 

Advisory Action dated 12 September 201 1, page 2. What Jou's provisional application 
states is the following: 



4. The method for a transport device when relays a broadcast frame, to add the 
address information of the previous hop from where the frame comes into the 
transmitted frame. 

5. The method according to claim 4, wherein: 

When a wireless transport device receives a broadcast frame whose "previous 
hop** field contains its own address, the device can drop the frame without any 
further processing. 

For example, a device X either sends or relays a broadcast frame to its neighbors 
Ml and N2. When Nl and N2 relay the frame, they both add X in the "previous 
hop" field of the frame. Most likely device X will receive both these relayed 
frames from Nl and N2. With its address contained in the frame, device X can 
immediately realized it should drop the frames without processing. 



Jou's provisional application, page 1. See also: 



To filter out echo frames, broadcast frames have to carry the address information of 
previous hop in the transmitted frame so once the previous hop receives the frames, it can 
ignore these echo frames without further processing. For example, a device X either 
sends or relays a broadcast frame to its neighbors Nl and N2. When Nt and N2 relay the 
frame, they both add X in the previous hop" field of the frame. Most likely device X 
will receive both these relayed frames from Nl and N2. With its address contained in the 
frame, device X can immediately realize it should drop the frames without processing. 



Jou's provisional application, page 3. 
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Regardless, Jou's provisional application does not state or imply that the 
"previous hop" field is a destination address field (in fact, Applicant cannot find the term 
"destination address" used anywhere in Jou's provisional application). This is important 
because the Examiner is using Jou to allegedly disclose the subject matter of "comparing 
the destination address of the packet with at least one predetermined multicast and/or 
broadcast address". Jou's provisional application simply does not disclose anything 
related to a destination address field or its use. Furthermore, the "previous hop" field 
disclosed in Jou's provisional application certainly does not contain a "destination 
address", as this field contains instead "address information of the previous hop from 
where the frame comes". See page 1, claim 4 (and claim 5) of Jou's provisional 
application. 

As stated above, the subject matter regarding using a destination 
address field (e.g., for containing a previous hop address) does not appear in Jou's 
provisional application . This subject matter regarding the destination address field 
therefore has the filing date (10 August 2004) of Jou's published application (and not the 
earlier filing date of Jou's provisional application). The filing date (10 August 2004) of 
Jou's published application is after the priority date (6 February 2006) of the instant 
application, and therefore the cited subject matter regarding the destination address field in 
paragraph 29 of Jou's published application does not qualify as prior art under 35 U.S.C. 
§ 102. Because the Examiner admits that Rune does not disclose certain subject matter 
from the claims, and some of that certain subject matter supposedly disclosed in Jou's 
published application is not prior art against the independent claims, then the combination 
of Rune and Jou does not disclose this certain subject matter. Applicant respectfully 
submits the § 103(a) rejections against the independent claims must fail. 
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b) Jou does not disclose the subject matter alleged by the Examiner 
(and therefore the combination of Rune and Jou does not disclose this 
subject matter): Second Reason 

Even if the cited sections of Jou's published application are prior art against 
the instant independent claims, Applicant respectfully submits that Jou's published 
application does not disclose the subject matter the Examiner asserts is disclosed by Jou's 
published application. For instance, the Examiner cites to paragraph 29 of Jou's published 
application (emphasis added): 

[0029] FIG. 5 illustrates the processing flow chart on 
receiving a broadcast frame. In step 500, a wireless transport device 
receives a broadcast frame. The wireless transport device will determine 
whether or not the DA filed (sic - should be "field") is the same as the 
local MAC address of this device (510) . If positive, the wireless transport 
device drops the frame because it is an echoed frame (step 530). 
Otherwise, it uses Auxiliary Address to verify whether this frame is 
received through the correct neighbor, namely in step 520, to look up the 
route table. Subsequently, in step 540, the wireless transport device 
determines whether the TA address is the neighboring node the frame 
should come from. If positive, then the wireless transport device relays the 
frame or performs other process (550), otherwise, drops the frame (step 
530). 

This section of Jou's published application indicates that a determination is made of 
whether or not the DA (destination address) is the same as the local MAC (media access 
control) address of the device. It is known in the art that a MAC address is a unique 
identifier assigned to network interfaces for communications on the physical network 
segment. What the sentence "If positive, the wireless transport device drops the frame 
because it is an echoed frame (step 530)" appears to mean is that the current device 
previously transmitted the frame, and the frame is being echoed back to the device. Thus, 
the device put the MAC address of itself into the frame, and transmitted the frame. When 
the device receives a frame that has its MAC address, the device then determines the 
frame is an echoed frame and can be ignored. See also paragraph 22 of Jou's published 
application (emphasis added): 
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[0022] Depending on the method in unicast routing path 
calculation, the forwarding table for unicast frames can be used as the table 
that is used to look up the incoming neighboring device for a broadcast 
frame originator (i.e. FIG. 2). In this case, there is no extra effort in 
generating the broadcast frame reduction table. The other method to reduce 
the resource spending on broadcast frames is to reduce the processing effort 
for echoed broadcast frames. For example, a device X either sends or relays 
a broadcast frame to its neighbors Nl and N2. When Nl and N2 relay the 
frame, most likely device X will receive both the frames. Using the method 
mentioned earlier can cause the frames being dropped eventually. However, 
a table lookup for each frame will be needed for device X. To relieve the 
processing load, Nl and N2 can both add the address of X inside the frame. 
When X receives a broadcast frame, it can check whether the frame is 
echoed from itself. If so, the frame can be dropped immediately without 
processing. Therefore, to filter out echo frames, broadcast frames have 
to carry the address information of previous hop in the transmitted 
frame. This can be achieved by using an unused field in the 802.1 1 MAC 
header. In broadcasting, the Address 3 (DA, destination address) of FIG. 3 
is not used. The "previous hop" information is carried in the location the 
Address 3 (DA, destination address). 

Moreover, the MAC address of the device is not a "broadcast address", as 
the MAC address is the address of the device itself: "The wireless transport device will 
determine whether or not the DA filed (sic - should be "field") is the same as the local 
MAC address of this device (510)." Paragraph 29 of Jou's published application. See 
also paragraph 22 of Jou's published application: "Therefore, to filter out echo frames, 
broadcast frames have to carry the address information of [the] previous hop in the 
transmitted frame." Another device receiving the frame with the MAC address of the 
previous hop is not going to determine the MAC address is a broadcast address or use the 
MAC address as a broadcast address. This means that the MAC address of a device will 
not be the same as the broadcast address. The same is true for a multicast address: a 
multicast address will not be the same as a MAC address. This is true because, by 
definition, the multicast address is to be used for communication with multiple 
addresses/devices, while a MAC address is made to be specific to a single device. 
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To put this a different way, any device receiving a packet with a destination 
address that is the same as a MAC address of one of the devices on a network should 
forward the packet toward the device having that MAC address. However, there is only 
one device in the network with that MAC address. Therefore, the MAC address is not a 
broadcast address (a packet addressed with a broadcast address is destined for every 
device in the network) or is not a multicast address (a packet addressed with a multicast 
address is destined for at least two devices in the network). 

In the Advisory Action dated 12 September 201 1, the Examiner states the 

following: 

•multicast/broadcast and destination address). The recitations broadcast/multicast address and multicast address are not defined by the 
daim; the specification does not provide a dear explanation of said terms. In the absence of an express intent to impart a novel meaning to 
the daim terms, the words are presumed to take on the ordinary and customary meanings attributed to them by those of ordinary skill in the 
art [MPEP 21 1 1.01 J. in mis case Jou's destination address (although MAC address of the previous hop) is considered a multicast address 
since it is a multicast destination address (as shown above and discussed in paragraph 0022>Jou). Applicants arguments do not show how 
the daims prevent a reasonable broadest interpretation of said terms would prevent such interpretation as supported by the Jou reference. 

Advisory Action dated 12 September 201 1, page 2. 

One skilled in the art knows what the terms "MAC address", "multicast 
address", and "broadcast address" are. See, e.g., 
http://en.wikipedia.org/wiki/MAC_address ("MAC address"), 
http://en.wikipedia.org/wiki/Multicast_address ("multicast address"), and 
http://en.wikipedia.org/wiki/Broadcast_address ("broadcast address"). In fact, it is known 
that a broadcast address in MAC (e.g., 802.1 1) is all ones, e.g., FFFFFFFF for 32 bits in 
hexadecimal. See paragraph 27 of Jou ("a broadcast frame in WITnet is a WDS frame 
with Receiver Address Field (please refer to FIG. 3) being, for instant (sic), 
Oxffffffffffff"), or http://en.wikipedia.org/wiki/MAC_address ("Packets sent to the 
broadcast address, all one bits, are received by all stations on a local area network. In 
hexadecimal the broadcast address would be FF:FF:FF:FF:FF:FF"). Jou is using the 
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broadcast address of Oxffffffffffff consistently with what is known in the art for one 
particular network and protocol. 

Additionally, even the term "destination address" is respectfully being read 
by the Examiner in a manner not consistent with the way one skilled in the art would read 
the term. Applicant's claim recites (in general) comparing the destination address of the 
packet with at least one multicast and/or broadcast address. In Jou's published 
application, a value in a destination address field is compared with a MAC address of the 
device receiving the packet. (See paragraph 29 of Jou's published application.) What is in 
the destination address field is not a "destination address" as this term is commonly used 
in the art. Instead, it is the MAC address of the previous hop. See the last sentence of 
paragraph 22 and paragraph 29 of Jou's published application. In fact, the actual 
"destination address" of the packet in Jou's published application appears to be in the 
Receiver Address Field and has a value of Oxffffffffffff. See paragraph 27 of Jou. Thus, 
even the term "destination address" is being read by the Examiner in a way that is not the 
way one skilled in the art would read this term. 

Therefore, Applicant respectfully submits that it is the Examiner who is 
interpreting the terms "multicast address" and "broadcast address" in a way that is not in 
accord with the way these terms would be interpreted by one skilled in the art. That is, 
one skilled in the art would not interpret MAC, broadcast, and multicast addresses in the 
way the Examiner is interpreting these terms in order to get Jou to read on the instant 
independent claims. 

Thus, for at least the above reasons, Jou's published application does not 
disclose at least the subject matter of "comparing the destination address of the packet 



49 



Appl. No. 10/587,979 

Corresponding to Notice ol Appeal filed 16 September 2011 

with at least one predetermined multicast and/or broadcast address", as recited in claim 22 
and generally in the other independent claims. 

Because the Examiner admits that Rune does not disclose the subject matter 
in the claims of "comparing the destination address of the packet with at least one 
predetermined multicast and/or broadcast address", and because Jou's published 
application does not disclose this certain subject matter, the combination of Rune and Jou 
does not disclose this subject matter. Applicant respectfully submits the 103(a) rejections 
against the independent claims must fail. 

c) The combination of Rune and Jou 

The Applicant has stated above that the combination of Rune and Jou does 
not disclose all features of the independent claims, including claim 22. For instance, the 
Examiner states the following: 

However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 

Outstanding Office Action, page 3. Therefore, the Examiner admits that Rune does not 
disclose this subject matter. The Applicant shows above that Jou's published application 
either is not valid prior art against the instant claims or does not teach or imply this subject 
matter. Therefore, the combination of Rune and Jou does not teach or imply this subject 
matter. 

Nonetheless, the Examiner states the following in the Advisory Action 
dated 12 September 201 1: 
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Examiner respectfully disagrees with applicants assertion that Rune does not teach "comparing the destinatino address of the packet with 
the at least one predetermined multicast and/or broadcast addess" and "preventing the transmission of the packet to a first device in 
reponse to the address* matching* (see applicants remarks pages 13-16) . This assertion amounts to attacking the reference kftviduariy. 
The office action relied upon the Jou reference for teaching 'comparing the destinatino address of trie packet with the at least one 
predetermined multicast and/or broadcast addess" (specially the step of 'comparing', 'destination address' and 'multicast address' are 
disclosed by the Jou reference). In response to applicant's arguments against the references individually, one cannot show nonobviousness 
by attacking references individually where the rejections are based on combinations of references. See In re Keller. 642 F.2d 413, 208 
USPG en (CCPA 1961); In re Merck & Co., 600 F,2d 1091, 231 USPQ 375 (Fed. Cir. 1966). In addition, examiner respectfully disagrees 
with applicant's statements that seem to imply that filtering is done (only?) by filtering out packets by type and not address. In contrast, even 
though Rune teaches filtering out by type. Rune also teaches filtering out by address {see paragraph 0215)- Therefore, one having ordinary 
skill in the art would take Rune (for teaching filtering out broadcast packets by address, and use Jou to learn how to fSter by address (Lb. 
comparing the destination address of the packet with multicast address). 



Applicant respectfully submits that Applicant has stated multiple times that the 



combination of Rune and Jou does not disclosed the features of the independent claims, as 



the Examiner admits that Rune does not disclose this subject matter and the Applicant 



shows above that Jou's published application either is not valid prior art against the instant 



claims or does not teach or imply this subject matter. If the Examiner admits that Rune 



does not disclose certain subject matter and Applicant shows that some or all of that 



subject matter is not disclosed or implied by Jou, then the combination of Rune and Jou 



cannot disclose or imply that subject matter. 



For sake of argument, however, Applicant will now show that even though 



the Examiner has admitted that Rune does not disclose "comparing the destination address 



of the packet with at least one predetermined multicast and/or broadcast address", and 



"preventing the transmission of the packet to a first device in response to the addresses 



matching", Applicant will now show the same. 



Applicant cannot find in Rune where a comparison is performed between a 



multicast and/or broadcast address and a destination address of a packet in order to prevent 



transmission of the packet or forward the packet. 



There are a number of indications that can include multicast addresses in 



Rune. See, e.g., paragraphs 156, 173, 186, and 187 of Rune. However, nowhere in these 



paragraphs (or any other paragraphs) of Rune can Applicant find a comparison that is 
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performed between a multicast address and a destination address of a packet in order to 
prevent transmission of the packet or forward the packet. 

Regarding broadcast addresses, Rune makes specific reference to these 
addresses in paragraphs 215 and 291, neither of which involves a comparison using a 
destination address and a broadcast address. 



Rune does discuss packet filtering. See paragraphs 195-218 of Rune. If 
this packet filtering is in any way related to a comparison that is performed between a 
multicast and/or broadcast address and a destination address of a packet in order to prevent 
transmission of the packet or forward the packet, Applicant cannot find in Rune where that 
is the case. In fact, Rune states the following (emphasis added): 

[0197] The NAL packet type filtering in the NAP is 
performed in the packet type filtering function 912, which is present only 
on the scatternet side of the NAP. The NAL packet type filtering, in some 
embodiments of the invention, is very simple: all NAPSA broadcast type 
and scatternet broadcast type packets are passed by the packet type 
filtering function 912 to the NAP-IPH , while all other packet types are 
passed to the address filtering function 914. 

This section of Rune appears to teach away from comparing a broadcast address and a 
destination address, as all broadcast type packets are simply forwarded. 

In paragraph 215, Rune states the following (emphasis added): 

[0215] For broadcast ARP replies received from the LAN, 
the address filtering process is much more complicated. The address 
filtering function first extracts the "target MAC address" from the ARP 
reply. This is the MAC address of the intended receiver of the ARP reply. 
In other words, this is the MAC address of the node that sent the ARP 
request (or possibly the ARP-route-request) that triggered the ARP reply. 
The target MAC address is extracted even though the destination 
address of the packet is a broadcast address. The target MAC address 
is then made sub ject to the same check as a destination address of a 
unicast packet If the target MAC address was not found in the address 
table or if it was found in the address table and the address table indicated 
that the corresponding node is located on the scatternet side of the NAP, the 
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packet is passed to the NAP-B. The address filtering function then has 
an option to convert the broadcast ARP reply into a unicast ARP reply 
by replacing the broadcast address with the target MAC address in the 
destination address field. The purpose of this option is to save resources 
(mainly bandwidth) in the scatternet. 

None of the highlighted (or any other portion) of this cited text indicates in any way that a 
comparison is performed between a multicast and/or broadcast address and a destination 
address of a packet in order to prevent transmission of the packet or forward the packet. 

What Rune states regarding broadcast types is the following (emphasis 

added) 

[0123] FIGS. 10-15 illustrate the coverage areas of the 
different broadcast types. The NAPSA broadcast type, as the name implies, 
is used to broadcast packets to a single NAPSA. This is illustrated in FIG. 
10 (which is similar to FIG. 8), where each isolated gray area 1000-1008 
represents a different NAPSA broadcast area. A NAPSA broadcast packet 
is not allowed to leave its broadcast area. Thus, NAPSA broadcast 
packets are not forwarded to the LAN and are not allowed to cross a 
NAPSA border. 

[0124] The scatternet broadcast type, as the name implies, is 
used to broadcast packets within the scatternet. This arrangement is 
illustrated in FIG. 1 1, where each contiguous gray area 1 100-1 106 
represents different broadcast areas for a scatternet broadcast packet. Such 
broadcast packets are not forwarded to the LAN. When more than one 
AD exists in a scatternet, the scatternet broadcast packets carrying higher 
layer protocol packets, i.e. packets from protocol layers above the NAL, 
e.g. IP, are not allowed to cross an AD border. These packets are 
consequently limited to a part of the scatternet belonging to the same AD. 
Scatternet broadcast packets that are not carrying packets from higher layer 
protocols, such as NAL control packets, however, are allowed to cross AD 
borders and may therefore still be broadcast in the whole scatternet. A NAL 
control packet does not encapsulate data from a higher protocol layer and is 
only used to transfer signaling and control information between NAL 
entities in different Bluetooth nodes. This arrangement is illustrated in FIG. 
12, where each contiguous gray area 1200 and 1202 represents the 
broadcast area of an NAL control packet. 

[0125] The AD broadcast type covers the LAN and any 
attached scatternets that are associated with the same AD as the LAN. 
These broadcast packets are forwarded by NAPs from/to the LAN to/from 
the scatternet, but the NAPSA borders in the scatternet are respected. This 
arrangement is illustrated in FIG. 13, where each contiguous gray area 
1300-1304 represents the broadcast area of an AD broadcast packet. An 
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AD broadcast packet is used to reach all the nodes in the AD (including the 
nodes on the LAN). All broadcast packets that are forwarded from the LAN 
to the scatternet are sent using the AD broadcast type. 

[0126] The scatternet- AD broadcast type is a special 
broadcast type used only for route requests. This broadcast type is, as the 
name implies, a combination of the scatternet broadcast type and the AD 
broadcast type. The scatternet-AD broadcast packets are distributed through 
the entire scatternet without respecting the NAPSA borders, as well as the 
entire AD via the NAPs. However, the NAPSA borders are respected after 
a scatternet-AD broadcast packet re-enters the scatternet via a NAP. 

Thus, in Rune, the NAPSA broadcast packets are not forward to a scatternet, and the 
scatternet broadcast packets are not forwarded to the LAN. However, these packets are 
not forwarded based on their broadcast type, which is defined by an indicator in a NAL 
(network adaptive layer) header (emphasis added): 

[0122] In addition to the routing protocol discussed above, 
the NAL also has a broadcast mechanism. (Note that broadcasting on the 
LAN is inherent in the shared medium and no "broadcast" mechanism is 
needed.) In accordance with embodiments of the invention, the NAL 
includes four different types of broadcasts: NAPSA broadcast, scatternet 
broadcast, AD broadcast, and scatternet-AD broadcast. The differences 
between broadcast types lie in the scope of the distribution and how the 
NAPs and other nodes at the NAPSA borders treat the different broadcast 
packets. Note that the broadcast type is defined by an indicator in the 
NAL header. In that sense, these different broadcast types can only exist in 
the scatternet. On the other hand, an Ethernet broadcast packet (originated 
on the LAN) that is forwarded from the LAN to the scatternet becomes an 
AD broadcast packet when it is forwarded into the scatternet. The broadcast 
type may be indicated in the NAL header, for example, with a two-bit 
indicator, as indicated in Table 2. 

Thus, the broadcast type is defined in Rune by an indicator in the NAL header. 

It is clear that filtering of broadcast packets in Rune is performed without 
examination of destination addresses for packets (emphasis added): 

[0196] The second main component of the invention is the 
packet filtering mechanism. As already mentioned, a NAP does not 
indiscriminately forward packets. Instead, it uses the packet filtering 
mechanisms (see FIG. 9) to reduce the number of unnecessarily forwarded 
packets. For example, forwarding is unnecessary when both the source and 
the destination node are located on the same side of the NAP. Furthermore, 
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NAL broadcast packets of the NAPSA broadcast type and the scatternet 
broadcast type are always blocked by the packet filtering mechanisms. 
Only those packets that pass the packet filtering mechanisms are 
forwarded to the scatternet. The generated useless traffic is a waste of 
resources, especially so in the scatternet where radio resources and 
processing resources are scarce. Furthermore, this could lead to the 
scatternet being flooded by traffic from the LAN with its shared medium 
and much higher capacity. Therefore, a packet filtering mechanism is 
needed in order to limit the forwarding of unnecessary traffic. The packet 
filtering is based on the destination address and the NAL packet type. 
Filtering may also be based on higher layer protocols. 

[0197] The NAL packet type filtering in the NAP is 
performed in the packet type filtering function 912, which is present only 
on the scatternet side of the NAP. The NAL packet type filtering , in some 
embodiments of the invention, is very simple: all NAPSA broadcast type 
and scatternet broadcast type packets are passed by the packet type 
filtering function 912 to the NAP-IPH, while all other packet types are 
passed to the address filtering function 914, 

Thus, packets having the NAPSA broadcast and scatternet broadcast types are filtered, and 
all other packet types are passed to an address filtering function, for forwarding to the 
correct address. See also, e.g., paragraphs [0222], [0224], [0237] of Rune. 

As is noted in paragraphs [0125] and [0197] from Rune above, packets 
having the AD broadcast type are forwarded, as are packets having the scatternet- AD 
broadcast type (see paragraphs [0126] and [0197]). 

Regarding multicast addresses, these appear to be related to route entries. 
See, e.g., the following: 

[0173] When (and if) the NAP-B of a NAP receives an 
encapsulated non-ARP-route-request (via the NAP-PFL), the NAP 
processes the non-ARP-route-request just like any node would process a 
received non-ARP-route-request. Thus, the NAP forwards the non-ARP- 
route-request into the scatternet, unless it already has a route to the 
destination node, or unless the NAP itself is the destination node. In the 
latter case, the NAP can immediately return an encapsulated non-ARP- 
route-reply. Then the next hop node in the route entry for the source node is 
indicated as "another NAP." This indication may be just a general 
indication, or it may be a specific indication that includes a NAP multicast 
address or the specific source MAC address of the Ethernet packet that 
carried the received encapsulated ARP-route-request. The choice between 
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general indication, NAP multicast address or source MAC address depends 
on whether broadcast packets, multicast packets or unicast packets are used 
to carry a corresponding encapsulated ARP-route-reply. 

See also paragraphs [0156], [0186], and [0187] of Rune. There are 
additional references to "multicast" in Rune, but none of these references relate to 
comparing a multicast and/or broadcast address and a destination address of a packet in 
order to prevent transmission of the packet or forward the packet. 

Applicant can find nowhere in Rune of disclosure or implication of a 
comparison that is performed between a multicast and/or broadcast address and a 
destination address of a packet in order to prevent transmission of the packet or forward 
the packet, as recited generally in the independent claims. Applicant has already shown 
above that Jou's published application either is not valid prior art against the instant claims 
or does not teach or imply this subject matter. Therefore, the combination of Rune and 
Jou does not teach or imply this subject matter. 

For at least these reasons, the § 103(a) rejections against claim 22 should be 

withdrawn. 

5. Claim 38 

Claim 38 recites the following: "The apparatus according to claim 27, 
wherein the processor is configured to cause the apparatus to forward at least broadcast 
packets relating to address acquisition to the first device". Claim 27 depends from claim 
22. 

The rejection to claim 38 has a legal error. Since claim 27 is rejected using 
a combination of Rune and Vasisht (and presumably Jou's published application, although 
this is not mentioned in the rejection of claim 27), then claim 38 should also use a 
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combination of Rune and Vasisht, and the rejection to claim 38 does not. Therefore, the 
rejection must be withdrawn. 

6. Claims 32, 34 

The Examiner rejected claim 32 under 103(a) being unpatentable over 
Rune in view of Jou. Applicant respectfully disagrees. 

Claim 32 is reproduced below. 

A memory storing a computer program, the computer 
program configured to control a processor to perform the following: 

check a destination address of a received packet; 

comparing the destination address of the packet with at least 
one predetermined multicast and/or broadcast address; 

preventing transmission of the packet in the system to a first 
device in response to the addresses matching; and 

forwarding the packet to at least the first device in response 
to the addresses not matching. 

The Examiner states the following: 

However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 

Outstanding Office Action, page 3. Therefore, the Examiner admits that Rune does not 
disclose at least the subject matter of comparing the destination address of the packet with 
at least one predetermined multicast and/or broadcast address and preventing the 
transmission of the packet to a first device in response to the addresses matching. 
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The Examiner then points to Jou for alleged disclosure of this subject 
matter. However, Jou does not disclose this subject matter for at least the following 
reasons. 



a) Jou does not disclose the subject matter alleged by the Examiner 
(and therefore the combination of Rune and Jou does not disclose this 
subject matter): First Reason 

The instant application has a priority date of 6 February 2004 under, e.g., 
M.P.E.P. §201.13, 35 U.S.C. §1 19 and 37 C.F.R. §1.55. That is, the priority date of 6 
February 2004 is based on a Finnish application filed on that date, which later became an 
international (P.C.T.) application filed on 4 February 2005. The international application 
entered national stage in the United States on 10 October 2006 as the instant application. 
A proper claim for priority was made at least in the Declaration filed on 10 October 2006. 
In fact, the U.S. Patent Publication no. 2007/0127394 of the instant application lists 
"Foreign Application Priority Data" as "Feb. 6, 2004", as shown by the following portion 
of the first page of this publication: 
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ABSTRACT 



The invention relates to a method of arranging comnjuni- 
calkin in a local area networking system comprising a first 
device, a second device and an intermediate nude for arrang- 
ing data iruu&iiiission between the first device and the second 
device. The second device is arranged to multicast and/or 
broadcast rncssagcti to devices in the system. The transmis- 
sion of multicast arxiA>r broadcast messages to the first 
device is prevented by the intcrworking means. 



Therefore, the priority date of the instant invention is 6 February 2004. 
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Turning to Jou, the published application 2005/0036489 was filed on 10 
August 2004, after the priority date of 6 February 2004 of the instant application. Jou's 
published application claims priority from provisional application 60/495,186, a copy of 
which is enclosed herein in section (9), "Evidence Appendix". This copy was also 
submitted in the after-final amendment dated 4 August 201 1 (as Appendix A). The Jou 
provisional application was filed on 15 August 2003. Therefore, for material to be cited 
under 35 U.S.C. §102 (and therefore §103) against the instant application, that material 
must exist prior to the priority date of the instant application of 6 February 2004. 

The Examiner cites to paragraph 29 of Jou's published application, which 
states the following: 

[0029] FIG. 5 illustrates the processing flow chart on 
receiving a broadcast frame. In step 500, a wireless transport device 
receives a broadcast frame. The wireless transport device will determine 
whether or not the DA filed is the same as the local MAC address of this 
device (510). If positive, the wireless transport device drops the frame 
because it is an echoed frame (step 530). Otherwise, it uses Auxiliary 
Address to verify whether this frame is received through the correct 
neighbor, namely in step 520, to look up the route table. Subsequently, in 
step 540, the wireless transport device determines whether the TA address 
is the neighboring node the frame should come from. If positive, then the 
wireless transport device relays the frame or performs other process (550), 
otherwise, drops the frame (step 530). 

The Examiner relies on this section of Jou's published application in order to assert that 
Jou's published application discloses the subject matter of "comparing the destination 
address of the packet with at least one predetermined multicast and/or broadcast address": 
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response lo the address not matching. However, Jou teaches comparing the destination 
address of the packet with at least one predetermined multicast and/or broadcast address; 
preventing, the transmission of the packet to a first device in response to the addresses 
matching; in response to the address not matching (see paragraph 0029 where a 
wireless transport device (intermediate node) receives a broadcast frame; the 
wireless transport device determines whether or not the Destination Address field is 
the same as the local MAC address (predetermined multicast address) of this device; 
if positive (in response the addresses matching), the wireless transport device drops 
the frame). It would have been obvious for a person having ordinary skill in the art to 

Final Office Action, dated 24 May 201 1. That is, the Examiner is relying on the statement 
"The wireless transport device will determine whether or not the DA [destination address] 
filed (sic - should be "field") is the same as the local MAC address of this device (510)" 
in paragraph 29 of Jou's published application in order for Jou's published application to 
disclose the subject matter in the instant claims of "comparing the destination address of 
the packet with at least one predetermined multicast and/or broadcast address". 

However, the sub ject matter regarding using a destination address field 
(e.g., for containing a previous hop address) does not appear in Jou's provisional 
application . This subject matter regarding a destination address field therefore has the 
filing date (10 August 2004) of Jou's published application (and not the earlier filing date 
of Jou's provisional application). The filing date (10 August 2004) of Jou's published 
application is after the priority date (6 February 2006) of the instant application, and 
therefore the cited subject matter regarding a destination address field in paragraph 29 of 
Jou's published application does not qualify as prior art under 35 U.S.C. §102. 

Consequently, the sections cited by the Examiner of Jou's published 
application cannot be cited as prior art against the claims of the instant application. 
Because the Examiner admits that Rune does not disclose certain subject matter from the 
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claims, and some of that certain subject matter supposedly disclosed in Jou's published 
application is not prior art against the independent claims, then the combination of Rune 
and Jou does not disclose this certain subject matter. Applicant respectfully submits the 
§ 103(a) rejections against the independent claims must fail. 

Applicant made similar arguments in the after-final Amendment dated 4 
August 201 1 . In response, the Examiner in the Advisory Action dated 12 September 20 1 1 
stated the following: 

In response to appficanfs argument trial the Jou reference is not valid because the provisional appScation does not contain the cited 
oaragraph {see applicant's remarks page 9-10) , it should be noted that Jou's provisional application sW have support for said paragraph 
(See second paragraph under 'summary of the invention* In page 3 where Jou teaches "When N1 and H2 relay the frame, they both add X 
In the "previous hop" field of the frame. Most Ukety device X will receive both these relayed frames from N1 and M2. VMth its address 
contained in the frame, device X can immediately realize (compare and determine) it should drop the frames without processing"} 

Advisory Action dated 12 September 201 1, page 2. What Jou's provisional application 
states is the following: 



4. The method for a transport device when relays a broadcast frame, to add the 
address information of the previous hop from where the frame comes into the 
transmitted frame. 

5. The method according to claim 4, wherein: 

When a wireless transport device receives a broadcast frame whose "previous 
hop" field contains its own address, the device can drop the frame without any 
further processing. 

For example, a device X either sends or relays a broadcast frame to its neighbors 
N1 and N2. When Nt and N2 relay the frame, they both add X in the "previous 
hop" field of the frame. Most likely device X will receive both these relayed 
frames from N 1 and N2. With its address contained in the frame, device X can 
immediately realized it should drop the frames without processing. 



Jou's provisional application, page 1. See also: 



To filter out echo frames, broadcast frames have to carry the address information of 
previous hop in the transmitted frame so once the previous hop receives the frames, it can 
ignore these echo frames without further processing. For example, a device X either 
sends or relays a broadcast frame to its neighbors Nl and N2. When Nt and N2 relay the 
frame, they both add X in the "previous hop'* fey 0 f the Most j^iy device X 
will receive both these relayed frames from N 1 and N2. With its address contained in the 
frame, device X can immediately realize it should drop the frames without processing. 



Jou's provisional application, page 3. 
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Regardless, Jou's provisional application does not state or imply that the 
"previous hop" field is a destination address field (in fact, Applicant cannot find the term 
"destination address" used anywhere in Jou's provisional application). This is important 
because the Examiner is using Jou to allegedly disclose the subject matter of "comparing 
the destination address of the packet with at least one predetermined multicast and/or 
broadcast address". Jou's provisional application simply does not disclose anything 
related to a destination address field or its use. Furthermore, the "previous hop" field 
disclosed in Jou's provisional application certainly does not contain a "destination 
address", as this field contains instead "address information of the previous hop from 
where the frame comes". See page 1, claim 4 (and claim 5) of Jou's provisional 
application. 

As stated above, the subject matter regarding using a destination 
address field (e.g., for containing a previous hop address) does not appear in Jou's 
provisional application . This subject matter regarding the destination address field 
therefore has the filing date (10 August 2004) of Jou's published application (and not the 
earlier filing date of Jou's provisional application). The filing date (10 August 2004) of 
Jou's published application is after the priority date (6 February 2006) of the instant 
application, and therefore the cited subject matter regarding the destination address field in 
paragraph 29 of Jou's published application does not qualify as prior art under 35 U.S.C. 
§ 102. Because the Examiner admits that Rune does not disclose certain subject matter 
from the claims, and some of that certain subject matter supposedly disclosed in Jou's 
published application is not prior art against the independent claims, then the combination 
of Rune and Jou does not disclose this certain subject matter. Applicant respectfully 
submits the § 103(a) rejections against the independent claims must fail. 
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b) Jou does not disclose the subject matter alleged by the Examiner 
(and therefore the combination of Rune and Jou does not disclose this 
subject matter): Second Reason 

Even if the cited sections of Jou's published application are prior art against 
the instant independent claims, Applicant respectfully submits that Jou's published 
application does not disclose the subject matter the Examiner asserts is disclosed by Jou's 
published application. For instance, the Examiner cites to paragraph 29 of Jou's published 
application (emphasis added): 

[0029] FIG. 5 illustrates the processing flow chart on 
receiving a broadcast frame. In step 500, a wireless transport device 
receives a broadcast frame. The wireless transport device will determine 
whether or not the DA filed (sic - should be "field") is the same as the 
local MAC address of this device (510) . If positive, the wireless transport 
device drops the frame because it is an echoed frame (step 530). 
Otherwise, it uses Auxiliary Address to verify whether this frame is 
received through the correct neighbor, namely in step 520, to look up the 
route table. Subsequently, in step 540, the wireless transport device 
determines whether the TA address is the neighboring node the frame 
should come from. If positive, then the wireless transport device relays the 
frame or performs other process (550), otherwise, drops the frame (step 
530). 

This section of Jou's published application indicates that a determination is made of 
whether or not the DA (destination address) is the same as the local MAC (media access 
control) address of the device. It is known in the art that a MAC address is a unique 
identifier assigned to network interfaces for communications on the physical network 
segment. What the sentence "If positive, the wireless transport device drops the frame 
because it is an echoed frame (step 530)" appears to mean is that the current device 
previously transmitted the frame, and the frame is being echoed back to the device. Thus, 
the device put the MAC address of itself into the frame, and transmitted the frame. When 
the device receives a frame that has its MAC address, the device then determines the 
frame is an echoed frame and can be ignored. See also paragraph 22 of Jou's published 
application (emphasis added): 
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[0022] Depending on the method in unicast routing path 
calculation, the forwarding table for unicast frames can be used as the table 
that is used to look up the incoming neighboring device for a broadcast 
frame originator (i.e. FIG. 2). In this case, there is no extra effort in 
generating the broadcast frame reduction table. The other method to reduce 
the resource spending on broadcast frames is to reduce the processing effort 
for echoed broadcast frames. For example, a device X either sends or relays 
a broadcast frame to its neighbors Nl and N2. When Nl and N2 relay the 
frame, most likely device X will receive both the frames. Using the method 
mentioned earlier can cause the frames being dropped eventually. However, 
a table lookup for each frame will be needed for device X. To relieve the 
processing load, Nl and N2 can both add the address of X inside the frame. 
When X receives a broadcast frame, it can check whether the frame is 
echoed from itself. If so, the frame can be dropped immediately without 
processing. Therefore, to filter out echo frames, broadcast frames have 
to carry the address information of previous hop in the transmitted 
frame. This can be achieved by using an unused field in the 802. 1 1 MAC 
header. In broadcasting, the Address 3 (DA, destination address) of FIG. 3 
is not used. The "previous hop" information is carried in the location the 
Address 3 (DA, destination address). 

Moreover, the MAC address of the device is not a "broadcast address", as 
the MAC address is the address of the device itself: "The wireless transport device will 
determine whether or not the DA filed (sic - should be "field") is the same as the local 
MAC address of this device (510)." Paragraph 29 of Jou's published application. See 
also paragraph 22 of Jou's published application: "Therefore, to filter out echo frames, 
broadcast frames have to carry the address information of [the] previous hop in the 
transmitted frame." Another device receiving the frame with the MAC address of the 
previous hop is not going to determine the MAC address is a broadcast address or use the 
MAC address as a broadcast address. This means that the MAC address of a device will 
not be the same as the broadcast address. The same is true for a multicast address: a 
multicast address will not be the same as a MAC address. This is true because, by 
definition, the multicast address is to be used for communication with multiple 
addresses/devices, while a MAC address is made to be specific to a single device. 
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To put this a different way, any device receiving a packet with a destination 
address that is the same as a MAC address of one of the devices on a network should 
forward the packet toward the device having that MAC address. However, there is only 
one device in the network with that MAC address. Therefore, the MAC address is not a 
broadcast address (a packet addressed with a broadcast address is destined for every 
device in the network) or is not a multicast address (a packet addressed with a multicast 
address is destined for at least two devices in the network). 

In the Advisory Action dated 12 September 201 1, the Examiner states the 

following: 

•multicast/broadcast and destination address). The recitations broadcast/multicast address and multicast address are not defined by the 
claim; the specification does not provide a dear explanation of said terms. In the absence of an express intent to impart a novel meaning to 
the claim terms, the words are presumed to take on the ordinary and customary meanings attributed to them by those of ordinary skill tn the 
art [MPEP 21 1 1.01]. in this case Jou's destination address (although MAC address of the previous hop) is considered a multicast address 
since it is a multicast destination address (as shown above and discussed in paragraph 0022>lou). Applicants arguments do not show how 
the claims prevent a reasonable broadest interpretation of said terms would prevent such interpretation as supported by the Jou reference. 

Advisory Action dated 12 September 201 1, page 2. 

One skilled in the art knows what the terms "MAC address", "multicast 
address", and "broadcast address" are. See, e.g., 
http://en.wikipedia.org/wiki/MAC_address ("MAC address"), 
http://en.wikipedia.org/wiki/Multicast_address ("multicast address"), and 
http://en.wikipedia.org/wiki/Broadcast_address ("broadcast address"). In fact, it is known 
that a broadcast address in MAC (e.g., 802.1 1) is all ones, e.g., FFFFFFFF for 32 bits in 
hexadecimal. See paragraph 27 of Jou ("a broadcast frame in WITnet is a WDS frame 
with Receiver Address Field (please refer to FIG. 3) being, for instant (sic), 
Oxffffffffffff '), or http://en.wikipedia.org/wiki/MAC_address ("Packets sent to the 
broadcast address, all one bits, are received by all stations on a local area network. In 
hexadecimal the broadcast address would be FF:FF:FF:FF:FF:FF"). Jou is using the 
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broadcast address of Oxffffffffffff consistently with what is known in the art for one 
particular network and protocol. 

Additionally, even the term "destination address" is respectfully being read 
by the Examiner in a manner not consistent with the way one skilled in the art would read 
the term. Applicant's claim recites (in general) comparing the destination address of the 
packet with at least one multicast and/or broadcast address. In Jou's published 
application, a value in a destination address field is compared with a MAC address of the 
device receiving the packet. (See paragraph 29 of Jou's published application.) What is in 
the destination address field is not a "destination address" as this term is commonly used 
in the art. Instead, it is the MAC address of the previous hop. See the last sentence of 
paragraph 22 and paragraph 29 of Jou's published application. In fact, the actual 
"destination address" of the packet in Jou's published application appears to be in the 
Receiver Address Field and has a value of Oxffffffffffff. See paragraph 27 of Jou. Thus, 
even the term "destination address" is being read by the Examiner in a way that is not the 
way one skilled in the art would read this term. 

Therefore, Applicant respectfully submits that it is the Examiner who is 
interpreting the terms "multicast address" and "broadcast address" in a way that is not in 
accord with the way these terms would be interpreted by one skilled in the art. That is, 
one skilled in the art would not interpret MAC, broadcast, and multicast addresses in the 
way the Examiner is interpreting these terms in order to get Jou to read on the instant 
independent claims. 

Thus, for at least the above reasons, Jou's published application does not 
disclose at least the subject matter of "comparing the destination address of the packet 
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with at least one predetermined multicast and/or broadcast address", as recited in claim 32 
and generally in the other independent claims. 

Because the Examiner admits that Rune does not disclose the subject matter 
in the claims of "comparing the destination address of the packet with at least one 
predetermined multicast and/or broadcast address", and because Jou's published 
application does not disclose this certain subject matter, the combination of Rune and Jou 
does not disclose this subject matter. Applicant respectfully submits the 103(a) rejections 
against the independent claims must fail. 

c) The combination of Rune and Jou 

The Applicant has stated above that the combination of Rune and Jou does 
not disclose all features of the independent claims, including claim 32. For instance, the 
Examiner states the following: 

However Rune does not explicitly teach comparing the destination address of the packet 
with at least one predetermined multicast and/or broadcast address; preventing, the 
transmission of the packet to a first device in response to the addresses matching; in 
response to the address not matching. However, Jou teaches comparing the destination 

Outstanding Office Action, page 3. Therefore, the Examiner admits that Rune does not 
disclose this subject matter. The Applicant shows above that Jou's published application 
either is not valid prior art against the instant claims or does not teach or imply this subject 
matter. Therefore, the combination of Rune and Jou does not teach or imply this subject 
matter. 

Nonetheless, the Examiner states the following in the Advisory Action 
dated 12 September 201 1: 
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Examiner respectfully disagrees with applicant's assertion *al Rune dees not teach 'comparing the destmatino address of the packet with 
the at least one predetermined multicast and/or broadcast addess" and "preventing the transmission of the packet to a first device in 
reponse to the addresss matching* (see applicants remarks pages 13-t6) . This assertion amounts to attacking the reference kj'rvkJuafly. 
The office action relied upon the Jou reference for teaching "comparing the destinaJino address of the packet with the at least one 
predetermined multicast and/or broadcast addess" (specially the step of 'comparing', •destination address' and 'multicast address' are 
disclosed by the Jou reference). In response to applicant's arguments against the references individually, one cannot show nonooviousness 
by attacking references individually where the rejections are based on combinations of references, See In re Keller, 642 F.2d 413, 208 
USPQ 871 (CCPA 1981); In re Merck & Co.. 600 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1966). In addition, examiner respectfully disagrees 
with applicant* s statements that seem to imply that filtering is done (only?) by filtering out packets by type and not address. In contrast, even 
though Rune teaches filtering out by type. Rune also teaches filtering out by address (see paragraph 0215). Therefore, one having ordinary 
skill in the art would take Rune (for teaching filtering out broadcast packets by address, and use Jou to learn how to filter by address (Ke. 
comparing the destination address of the packet with multicast address). 



Applicant respectfully submits that Applicant has stated multiple times that the 



combination of Rune and Jou does not disclosed the features of the independent claims, as 



the Examiner admits that Rune does not disclose this subject matter and the Applicant 



shows above that Jou's published application either is not valid prior art against the instant 



claims or does not teach or imply this subject matter. If the Examiner admits that Rune 



does not disclose certain subject matter and Applicant shows that some or all of that 



subject matter is not disclosed or implied by Jou, then the combination of Rune and Jou 



cannot disclose or imply that subject matter. 



For sake of argument, however, Applicant will now show that even though 



the Examiner has admitted that Rune does not disclose "comparing the destination address 



of the packet with at least one predetermined multicast and/or broadcast address", and 



preventing the transmission of the packet to a first device in response to the addresses 



matching", Applicant will now show the same. 



Applicant cannot find in Rune where a comparison is performed between a 



multicast and/or broadcast address and a destination address of a packet in order to prevent 



transmission of the packet or forward the packet. 



There are a number of indications that can include multicast addresses in 



Rune. See, e.g., paragraphs 156, 173, 186, and 187 of Rune. However, nowhere in these 



paragraphs (or any other paragraphs) of Rune can Applicant find a comparison that is 
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performed between a multicast address and a destination address of a packet in order to 
prevent transmission of the packet or forward the packet. 

Regarding broadcast addresses, Rune makes specific reference to these 
addresses in paragraphs 215 and 291, neither of which involves a comparison using a 
destination address and a broadcast address. 



Rune does discuss packet filtering. See paragraphs 195-218 of Rune. If 
this packet filtering is in any way related to a comparison that is performed between a 
multicast and/or broadcast address and a destination address of a packet in order to prevent 
transmission of the packet or forward the packet, Applicant cannot find in Rune where that 
is the case. In fact, Rune states the following (emphasis added): 

[0197] The NAL packet type filtering in the NAP is 
performed in the packet type filtering function 912, which is present only 
on the scatternet side of the NAP. The NAL packet type filtering, in some 
embodiments of the invention, is very simple: all NAPSA broadcast type 
and scatternet broadcast type packets are passed by the packet type 
filtering function 912 to the NAP-IPH , while all other packet types are 
passed to the address filtering function 914. 

This section of Rune appears to teach away from comparing a broadcast address and a 
destination address, as all broadcast type packets are simply forwarded. 

In paragraph 215, Rune states the following (emphasis added): 

[0215] For broadcast ARP replies received from the LAN, 
the address filtering process is much more complicated. The address 
filtering function first extracts the "target MAC address" from the ARP 
reply. This is the MAC address of the intended receiver of the ARP reply. 
In other words, this is the MAC address of the node that sent the ARP 
request (or possibly the ARP-route-request) that triggered the ARP reply. 
The target MAC address is extracted even though the destination 
address of the packet is a broadcast address. The target MAC address 
is then made subject to the same check as a destination address of a 
unicast packet If the target MAC address was not found in the address 
table or if it was found in the address table and the address table indicated 
that the corresponding node is located on the scatternet side of the NAP, the 
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packet is passed to the NAP-B. The address filtering function then has 
an option to convert the broadcast ARP reply into a unicast ARP reply 
by replacing the broadcast address with the target MAC address in the 
destination address field. The purpose of this option is to save resources 
(mainly bandwidth) in the scatternet. 

None of the highlighted (or any other portion) of this cited text indicates in any way that a 
comparison is performed between a multicast and/or broadcast address and a destination 
address of a packet in order to prevent transmission of the packet or forward the packet. 

What Rune states regarding broadcast types is the following (emphasis 

added) 

[0123] FIGS. 10-15 illustrate the coverage areas of the 
different broadcast types. The NAPSA broadcast type, as the name implies, 
is used to broadcast packets to a single NAPSA. This is illustrated in FIG. 
10 (which is similar to FIG. 8), where each isolated gray area 1000-1008 
represents a different NAPSA broadcast area. A NAPSA broadcast packet 
is not allowed to leave its broadcast area. Thus, NAPSA broadcast 
packets are not forwarded to the LAN and are not allowed to cross a 
NAPSA border. 

[0124] The scatternet broadcast type, as the name implies, is 
used to broadcast packets within the scatternet. This arrangement is 
illustrated in FIG. 1 1, where each contiguous gray area 1 100-1 106 
represents different broadcast areas for a scatternet broadcast packet. Such 
broadcast packets are not forwarded to the LAN. When more than one 
AD exists in a scatternet, the scatternet broadcast packets carrying higher 
layer protocol packets, i.e. packets from protocol layers above the NAL, 
e.g. IP, are not allowed to cross an AD border. These packets are 
consequently limited to a part of the scatternet belonging to the same AD. 
Scatternet broadcast packets that are not carrying packets from higher layer 
protocols, such as NAL control packets, however, are allowed to cross AD 
borders and may therefore still be broadcast in the whole scatternet. A NAL 
control packet does not encapsulate data from a higher protocol layer and is 
only used to transfer signaling and control information between NAL 
entities in different Bluetooth nodes. This arrangement is illustrated in FIG. 
12, where each contiguous gray area 1200 and 1202 represents the 
broadcast area of an NAL control packet. 

[0125] The AD broadcast type covers the LAN and any 
attached scatternets that are associated with the same AD as the LAN. 
These broadcast packets are forwarded by NAPs from/to the LAN to/from 
the scatternet, but the NAPSA borders in the scatternet are respected. This 
arrangement is illustrated in FIG. 13, where each contiguous gray area 
1300-1304 represents the broadcast area of an AD broadcast packet. An 
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AD broadcast packet is used to reach all the nodes in the AD (including the 
nodes on the LAN). All broadcast packets that are forwarded from the LAN 
to the scatternet are sent using the AD broadcast type. 

[0126] The scatternet- AD broadcast type is a special 
broadcast type used only for route requests. This broadcast type is, as the 
name implies, a combination of the scatternet broadcast type and the AD 
broadcast type. The scatternet-AD broadcast packets are distributed through 
the entire scatternet without respecting the NAPSA borders, as well as the 
entire AD via the NAPs. However, the NAPSA borders are respected after 
a scatternet-AD broadcast packet re-enters the scatternet via a NAP. 

Thus, in Rune, the NAPSA broadcast packets are not forward to a scatternet, and the 
scatternet broadcast packets are not forwarded to the LAN. However, these packets are 
not forwarded based on their broadcast type, which is defined by an indicator in a NAL 
(network adaptive layer) header (emphasis added): 

[0122] In addition to the routing protocol discussed above, 
the NAL also has a broadcast mechanism. (Note that broadcasting on the 
LAN is inherent in the shared medium and no "broadcast" mechanism is 
needed.) In accordance with embodiments of the invention, the NAL 
includes four different types of broadcasts: NAPSA broadcast, scatternet 
broadcast, AD broadcast, and scatternet-AD broadcast. The differences 
between broadcast types lie in the scope of the distribution and how the 
NAPs and other nodes at the NAPSA borders treat the different broadcast 
packets. Note that the broadcast type is defined by an indicator in the 
NAL header. In that sense, these different broadcast types can only exist in 
the scatternet. On the other hand, an Ethernet broadcast packet (originated 
on the LAN) that is forwarded from the LAN to the scatternet becomes an 
AD broadcast packet when it is forwarded into the scatternet. The broadcast 
type may be indicated in the NAL header, for example, with a two-bit 
indicator, as indicated in Table 2. 

Thus, the broadcast type is defined in Rune by an indicator in the NAL header. 

It is clear that filtering of broadcast packets in Rune is performed without 
examination of destination addresses for packets (emphasis added): 

[0196] The second main component of the invention is the 
packet filtering mechanism. As already mentioned, a NAP does not 
indiscriminately forward packets. Instead, it uses the packet filtering 
mechanisms (see FIG. 9) to reduce the number of unnecessarily forwarded 
packets. For example, forwarding is unnecessary when both the source and 
the destination node are located on the same side of the NAP. Furthermore, 
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NAL broadcast packets of the NAPSA broadcast type and the scatternet 
broadcast type are always blocked by the packet filtering mechanisms. 
Only those packets that pass the packet filtering mechanisms are 
forwarded to the scatternet. The generated useless traffic is a waste of 
resources, especially so in the scatternet where radio resources and 
processing resources are scarce. Furthermore, this could lead to the 
scatternet being flooded by traffic from the LAN with its shared medium 
and much higher capacity. Therefore, a packet filtering mechanism is 
needed in order to limit the forwarding of unnecessary traffic. The packet 
filtering is based on the destination address and the NAL packet type. 
Filtering may also be based on higher layer protocols. 

[0197] The NAL packet type filtering in the NAP is 
performed in the packet type filtering function 912, which is present only 
on the scatternet side of the NAP. The NAL packet type filtering , in some 
embodiments of the invention, is very simple: all NAPSA broadcast type 
and scatternet broadcast type packets are passed by the packet type 
filtering function 912 to the NAP-IPH, while all other packet types are 
passed to the address filtering function 914. 

Thus, packets having the NAPSA broadcast and scatternet broadcast types are filtered, and 
all other packet types are passed to an address filtering function, for forwarding to the 
correct address. See also, e.g., paragraphs [0222], [0224], [0237] of Rune. 

As is noted in paragraphs [0125] and [0197] from Rune above, packets 
having the AD broadcast type are forwarded, as are packets having the scatternet- AD 
broadcast type (see paragraphs [0126] and [0197]). 

Regarding multicast addresses, these appear to be related to route entries. 
See, e.g., the following: 

[0173] When (and if) the NAP-B of a NAP receives an 
encapsulated non-ARP-route-request (via the NAP-PFL), the NAP 
processes the non-ARP-route-request just like any node would process a 
received non-ARP-route-request. Thus, the NAP forwards the non-ARP- 
route-request into the scatternet, unless it already has a route to the 
destination node, or unless the NAP itself is the destination node. In the 
latter case, the NAP can immediately return an encapsulated non-ARP- 
route-reply. Then the next hop node in the route entry for the source node is 
indicated as "another NAP." This indication may be just a general 
indication, or it may be a specific indication that includes a NAP multicast 
address or the specific source MAC address of the Ethernet packet that 
carried the received encapsulated ARP-route-request. The choice between 
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general indication, NAP multicast address or source MAC address depends 
on whether broadcast packets, multicast packets or unicast packets are used 
to carry a corresponding encapsulated ARP-route-reply. 

See also paragraphs [0156], [0186], and [0187] of Rune. There are 
additional references to "multicast" in Rune, but none of these references relate to 
comparing a multicast and/or broadcast address and a destination address of a packet in 
order to prevent transmission of the packet or forward the packet. 

Applicant can find nowhere in Rune of disclosure or implication of a 
comparison that is performed between a multicast and/or broadcast address and a 
destination address of a packet in order to prevent transmission of the packet or forward 
the packet, as recited generally in the independent claims. Applicant has already shown 
above that Jou's published application either is not valid prior art against the instant claims 
or does not teach or imply this subject matter. Therefore, the combination of Rune and 
Jou does not teach or imply this subject matter. 

For at least these reasons, the § 103(a) rejections against claim 32 should be 

withdrawn. 

B. Second grounds for rejection 

Claims 19, 20, 26, 27, and 33 stand rejected under 35 U.S.C. § 103(a) over 
Rune in view of Vasisht. Applicant respectfully disagrees. 

First, it should be noted that claims 19, 20, 26, 27, and 33 are dependent 
claims that depend from independent claims 16 (claims 19 and 20), 22 (claims 26 and 27) 
and 32 (claim 33). Consequently, the rejections to claims 19, 20, 26, 27, and 33 should be 
based on a combination of Rune, Jou (Jou's published application) and Vasisht, and the 
rejections are not. Therefore, these rejections should fail for at least this reason. 
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a) Claims 19, 26, 33 

Claim 19 recites "A method as claimed in claim 16, wherein the packet is 
received from a second device, and wherein the first device belongs to a mobile handheld 
subcommittee domain of a universal plug and play system and the second device belongs 
to a home network version 1 domain of the universal plug and play system." All Vasisht 
adds to Rune (or the combination of Rune and Jou's published application) is that 
universal plug and play is an example of a standard to enable home networking. See 
paragraph 7 of Vasisht. 

However, the combination of claims 16 and 19 indicate that a packet may 
or may not be transmitted to the mobile handheld subcommittee domain of a universal 
plug and play system based on whether the destination address of the packet does not 
match or matches (respectively) at least one multicast or broadcast address. A stated 
above, Rune alone (or the combination of Rune and Jou's published application) does not 
disclose or imply this subject matter, and Vasisht also does not disclose or imply this 
subject matter. Therefore, the combination of Rune and Vasisht (or the combination of 
Rune and Jou's published application and Vasisht) does not disclose this subject matter 
and the § 103(a) rejections to claim 19 should be withdrawn. 

b) Claims 20, 27 

Claim 20 recites "A method as claimed in claim 19, wherein transmission 
of universal plug and play discovery multicast packets to the first device is prevented." 
Nowhere does Rune alone or Vasisht alone (or Jou's published application alone) indicate 
that universal plug and play discovery multicast packets to a first device belonging to a 
mobile handheld subcommittee domain of a universal plug and play system are prevented. 
Therefore, the combination of Rune and Vasisht (or Rune and Jou's published application 
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and Vasisht) does not disclose that universal plug and play discovery multicast packets to 
a first device belonging to a mobile handheld subcommittee domain of a universal plug 
and play system are prevented. For at least this reason, the § 103(a) rejections to claim 20 
should be withdrawn. 

C. Third grounds for rejection 

The third grounds for rejection presented for review by the Board is 
whether claim 36 is patentable under 35 U.S.C. § 103(a) over Rune in further view of 
Tung, U.S. Patent Publication no. 2006/0136562. 

First, it should be noted that claim 36 is dependent from independent claim 
22. Consequently, the rejections to claim 36 should be based on a combination of Rune, 
Jou (Jou's published application) and Tung, and the rejections are not. Therefore, these 
rejections should fail for at least this reason. 

Claim 36 recites "The apparatus according to claim 22, wherein the 
processor is configured to check whether the first device is in sleep mode and, when the 
first device is in sleep mode, the processor is configured to wake up the first device before 
forwarding the packet to the first device." 

It should be noted that Tung is incomprehensible. For instance, and as only 
one of many examples, Tung states the following (emphasis added): 

[0016] As shown in FIG. 2, personal computer 1 1 connects 
to the Internet and operates in a reduced power mode when not receiving 
any service request from the Internet. When a service request is received 
via a personal network server 11 (i.e. personal computer 11) . the 
Internet user sends a request for the domain name "home.com" to domain 
name server 12. Domain name server 12 sends a wake-up signal to the 
network server (personal computer 11) represented by the domain name 
to wake up personal computer 1 1 from the suspended state, enabling 
personal computer to operate in a normal mode. Next, domain name server 
12 assigns an IP address "203.56.56.56" corresponding to personal 
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computer 1 1 according to built-in domain names and corresponding 
relationships for IP addresses, and responds to the request with the assigned 
IP address. 

How does the network server (personal computer) receive a request while the network 
server (personal computer) is asleep? And if the service request is received via the 
network server, why does an Internet user send a request to a domain name server? 

Regardless, the combination of claim 36 and claim 22 will wake up the first 
device prior to sending a packet to the first device and then will send a packet to the first 
device. Inasmuch as Applicant can tell by reading Tung, Tung does not appear to send a 
packet to the "network server" after waking the "network server" up. For instance, Tung 
states the following: 

[0016] As shown in FIG. 2, personal computer 1 1 connects 
to the Internet and operates in a reduced power mode when not receiving 
any service request from the Internet. When a service request is received 
via a personal network server 1 1 (i.e. personal computer 1 1), the Internet 
user sends a request for the domain name "home.com" to domain name 
server 12. Domain name server 12 sends a wake-up signal to the network 
server (personal computer 1 1) represented by the domain name to wake up 
personal computer 1 1 from the suspended state, enabling personal 
computer to operate in a normal mode. Next, domain name server 12 
assigns an IP address "203.56.56.56" corresponding to personal computer 
1 1 according to built-in domain names and corresponding relationships for 
EP addresses, and responds to the request with the assigned IP address . 



[0022] In step S35, when a request for the domain name is 
received, a wake-up signal is sent to the network server for switching the 
network server to a normal mode, and an EP address corresponding to the 
server name is assigned according to the link. 

[0023] In step S36, the domain name server responds to 
the request with the assigned IP address . 

That is, it appears (inasmuch as Applicant can tell) that in Tung, a domain name server 
receives a request, wakes a "network server", then the domain name server responds to the 
request. No packet appears to be sent from the domain name server to the network server 
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after the network server is woken up. Therefore, at least the subject matter of "wherein 
the processor is configured to check whether the first device is in sleep mode and, when 
the first device is in sleep mode, the processor is configured to wake up the first device 
before forwarding the packet to the first device" is not taught or implied by Tung. 



Rune (and Jou's published application) does not disclose or imply this 



subject matter. Therefore, the combination of Rune and Tung (or Rune and Jou's 
published application and Tung) does not disclose or imply the subject matter in claim 36, 
and the § 103(a) rejections to claim 36 should be withdrawn. 



Conclusion 

For at least the above reasons, the Applicant contends that claims 16-28, 



32-34, 36, and 38 are patentable over the cited references. The Applicant respectfully 
requests the Board reverse the final rejection in the Office Action of 24 May 201 1, and 
further that the Board rule that the pending claims are patentable over the cited references. 

Respectfully submitted: 
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(8) CLAIMS APPENDIX 
1.-15. (Cancelled) 

1 6. A method comprising: 

checking a destination address of a received packet; 

comparing the destination address of the packet with at least one 
predetermined multicast and/or broadcast address; 

preventing the transmission of the packet to a first device in response to the 
addresses matching; and 

forwarding the packet to at least the first device in response to the 
addresses not matching. 

17. A method as claimed in claim 16, wherein the packet is received from a 
second device, and wherein the method further comprises connecting a first network 
comprising the first device to a second network comprising the second device, and 
wherein the first and second networks use different data transmission protocols. 

18. A method as claimed in claim 16, wherein the destination address is an 
internet protocol address. 

19. A method as claimed in claim 16, wherein the packet is received from a 
second device, and wherein the first device belongs to a mobile handheld subcommittee 
domain of a universal plug and play system and the second device belongs to a home 
network version 1 domain of the universal plug and play system. 



79 



Appl. No. 10/587,979 

Corresponding to Notice ol Appeal filed 16 September 2011 

20. A method as claimed in claim 19, wherein transmission of universal plug 
and play discovery multicast packets to the first device is prevented. 

21. A system comprising: 
a first device; 

a second device; and 

an intermediate node configured to arrange data transmission between the 
first device and the second device; 

wherein at least the second device is configured to multicast and/or 
broadcast packets to devices in the system, wherein the intermediate node is configured to 
check a destination address of a packet received from the second device, the intermediate 
node is configured to compare the destination address of the packet with at least one 
predetermined multicast and/or broadcast address, and wherein the intermediate node is 
configured to prevent the transmission of the packet to the first device in response to the 
addresses matching, and wherein the intermediate node is configured to forward the packet 
to at least the first device in response to the addresses not matching. 

22. An apparatus comprising: 
a processor configured to 

check a destination address of a received packet, ; 

compare the destination address of the packet with at least one 
predetermined multicast and/or broadcast address; 

prevent the transmission of the packet to a first device in response to the 
addresses matching; and 



80 



Appl. No. 10/587,979 

Corresponding to Notice of Appeal filed 16 September 2011 

forward the packet to at least the first device in response to the addresses 

not matching. 

23. The apparatus according to claim 22, wherein the packet is received from a 
second device, and wherein the processor is configured to cause the apparatus to connect a 
first network comprising the first device to a second network comprising the second 
device and the first and second networks use different data transmission protocols. 

24. The apparatus according to claim 23, wherein the processor is configured 
to cause the apparatus to perform data transmission between an BEEE 802-based network 
to which the second device belongs and a bluetooth network to which the first device 
belongs. 

25. The apparatus according to claim 22, wherein the destination address is an 
internet protocol address. 

26. The apparatus according to claim 22, wherein the packet is received from a 
second device, and wherein the processor is configured to cause the apparatus to provide 
data transmission between the first device belonging to a mobile handheld subcommittee 
domain of a universal plug and play system and the second device belonging to a home 
network version 1 domain of the universal plug and play system. 

27. The apparatus according to claim 26, wherein 

the processor is configured to prevent transmission of universal plug and 
play discovery multicast packets to the first device. 
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28. The apparatus according to claim 22, wherein the processor is configured 
to check, in addition to the comparison of the destination address of the packet with at 
least one predetermined multicast and/or broadcast address, if the packet complies with 
one or more further message transmission conditions, and the processor is configured to 
allow forwarding of the packet to the first device in response to the packet complying 
with the one or more further message transmission conditions. 

29. -31. (Canceled) 

32. A memory storing a computer program, the computer program configured 
to control a processor to perform the following: 

check a destination address of a received packet; 

comparing the destination address of the packet with at least one 
predetermined multicast and/or broadcast address; 

preventing transmission of the packet in the system to a first device in 
response to the addresses matching; and 

forwarding the packet to at least the first device in response to the addresses 

not matching. 

33. A memory according to claim 32, wherein the computer program is further 
configured to control the processor to prevent transmission of universal plug and play 
discovery multicast packets to the first device. 
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34. A memory according to claim 32, wherein the computer program is further 
configured to control the processor to compare one or more properties of the packet to 
properties specified in predetermined transmission conditions to determine whether the 
packet should be forwarded to the first device. 

35. (Canceled) 

36. The apparatus according to claim 22, wherein the processor is configured to 
check whether the first device is in sleep mode and, when the first device is in sleep mode, 
the processor is configured to wake up the first device before forwarding the packet to the 
first device. 

37. (Canceled) 

38. The apparatus according to claim 27, wherein the processor is configured to 
cause the apparatus to forward at least broadcast packets relating to address acquisition to 
the first device 

END OF CLAIMS 
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(9) EVIDENCE APPENDIX 

The following is a copy of U.S. provisional application 60/495,186. This 
copy was submitted as an Appendix in the after- final response filed on 4 August 201 1. 
The Examiner responded to this Appendix and the corresponding arguments in the 
Advisory Action dated 12 September 201 1, so it is believed the Examiner entered the copy 
of U.S. provisional application 60/495,186. 

The following is a copy of U.S. provisional application 60/495,186. 
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Methods and Apparatus for Broadcast Traffic Reduction 
on a Wireless Transport Network 

References Cited 

• US Patent Document 5,570,366, Baker, et al„ "Broadcast/multicast filtering by 
the bridge-based access point," October 29, 1996. 

♦ TJS Patent Document 6,549,786, R Y. M Cheung, "Method and apparatus for 
connecting a wireless LAN to a wired LAN," April 15, 2003. 

Claims 

The embodiments of the invention cJaim the following: 

1 . The method for a device to calculate a tabic that each entry contains the 
neighboring device from which a broadcast frame originated from a particular 
device can be received. 

2 . The method according to claim 1 , further comprising the steps of: 

for broadcast frames originated from the particular device, only the ones relayed 
through the listed neighboring device can be accepted. Broadcast frames coming 
through incorrect neighboring device are duplicates and should be ignored or 
dropped, 

3. The method according to claim 1 , farther comprising the steps of: 

carrying the name or address of the originator wireless transport device as part of 
the broadcast frames to facilitate the filtering on broadcast frames. 

4. The method for a transport device when relays a broadcast frame, to add the 
address information of the previous hop from where the frame comes into the 
transmitted frame. 

5. The method according to claim 4, wherein: 

When a wireless transport device receives a broadcast frame whose "previous 
bop" field contains its own address, the device can drop the frame without any 
further processing. 

For example, a device X either sends or relays a broadcast frame to its neighbors 
Nl and N2. When Nl and N2 relay the frame, they both add X in the "previous 
hop" field of the frame. Most likely device X will receive both these relayed 
frames from Nl and N2. With its address contained in the frame, device X can 
immediately realized it should drop the frames without processing. 
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6. The method to embed the announcement information of a newly associated 
wifeless client of a transport device into a broadcast frame the client generates if it 
is the first frame from the client system into the network 

7. The election among the multiple edge devices connecting the wireless network to 
a wired network to enable only one edge device to relay broadcast traffic across 
the wired and wireless network. 

Description 

THE FIELD OF THE INVENTION 

The present invention relates to communications systems that comprise wireless networks. 
The invention is particularly concerned with reducing transmission information frames on 
the wireless networks and across the wireless and wired border line and is most useful in 
networks requiring multi-hop wireless communication. 

BACKGROUND OF THE INVENTION 

A wireless transport network is a network comprises a plurality of wirelessly connected 
devices that are responsible for relaying traffic for associated mobile clients- An example 
of a wireless transport network is a plurality of IEEE S02.l l capable devices that provide 
transport service for IEEE 802.1 1 or Bluetooth capable clients such as laptop computers, 
PDA (personal digital assistant), and the like. The said network can further comprise one 
or more connections to a wired network through one or multiple edge devices. The edge 
devices are equipped and capable of both wireless and wired communication. An 
example is shown in FIG. 1* 

In a wireless transport network, efficient reduction of unnecessary broadcast traffic is 
critical. The transmission medium (the air) by nature is shared, therefore broadcast is a 
convenient way of communication in wireless networks for there is no need to transmit 
multiple times for a multi-destined frame. Once an originator broadcasts a frame to all its 
neighboring devices^ all, or some, of its neighboring devices will have to relay the frame 
for other remote devices. For any device that is a neighbor of multiple devices that arc 
responsible for relaying broadcast frames, it receives multiple copies of the same frame. 
One simple example is once a device sends out a broadcast frame, it immediately 
receives multiple copies of the exact frame if there arc multiple neighboring devices 
perform relay function for the frame. Unless a filtering method is implemented on the 
devices, in the worst case one single broadcast frame may be duplicated in an exponential 
growth fashion and saturate the network and waste device processing time. In the worst 
case, these frames may loop around the network until the end of their lives. 

Reducing the unnecessary broadcast frames can prevent frame looping, reduce total 
traffic amount hence preserve network bandwidth, and save device processing effort 
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PRIOR ART 

Prior art techniques in saving bandwidth on wireless network include software algorithms 
to select relay nodes for broadcast traffic, and maintaining sequence numbers of frames 
originated from each device to discard duplicates. 

US Patent number 5470,366 describes a method to fitter frames from a wired network to 
a wireless access point via configured protocol parameters. 

Present invention provides more efficient methods to filter unnecessary broadcast traffic 
and the techniques are more suitable to be implemented in firmware or hardware to 
enhance forwarding throughput 

US Patent number 6,549,786 claims the mechanism to set up a plurality of wireless nodes 
and a plurality of wired-wireless edge access points to form a local area network. The 
internetworking edge access points are used to relay traffic for wireless nodes unless the 
source and destination pair can communicate with each other directly. The wireless nodes 
actively select which access point it should be associated with, and determines whether it 
needs an AP*s help to send messages, This addresses only the client-access point 
architecture and covers only basic connectivity issues. 

SUMMARY OF THE INVENTION 

Each wi reless transport device calculates a table that each entry (FIG. 2) contains the 
neighboring device from which a broadcast frame originated from a particular device can 
be received. For broadcast frames originated from a particular device, only the frames 
relayed through the listed neighboring device can be accepted Broadcast frames coming 
through incorrect neighboring device are duplicates and should be ignored. To facilitate 
the above filtering function, the broadcast frames have to cany the name or address of the 
originator wireless transport device. Note the frame may have come from a client of the 
wireless transport device therefore it is not the real source of the frame. 

To filter out echo frames, broadcast frames have to carry the address information of 
previous hop in the transmitted frame so once the previous hop receives the frames, it can 
ignore these echo frames without further processing. For example, a device X either 
sends or relays a broadcast frame to its neighbors Nl and N2. When Nl and N2 relay the 
frame, they both add X in the previous hop" field of the frame. Most likely device X 
will receive both these relayed frames from Nl and N2, With its address contained in the 
frame, device X can immediately realize it should drop the frames without processing. 

Client membership announcement of a newly associated wireless client of a transport 
device is embedded into a broadcast frame the client generates, if it is the first frame from 
the client system. If the client is running common network layer protocols, the first frame 
is likely a broadcast frame. For example, in an IP network, the first frame from a newly 
booted up station usually is a broadcast frame containing either DHCP request or an ARP 
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request. The client membership announcement is piggybacked into the broadcast frame 
which saves the introduction of two different frames. 

In case there are more than one edge device connecting the wireless network to a wired 
network, our invention is the election among the edge devices to enable only one edge 
device to relay broadcast traffic across the wired and wireless network. 



BRIEF DESCRIPTION Of THE DRAWINGS 

FIG. 1 illustrates an example of a wireless transport network. 
FIG, 2 is an example of a broadcast receiving neighbor table. 
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Drawings 
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(10) RELATED PROCEEDING APPENDK 

There are no known decisions rendered by a court or the Board 
proceeding identified pursuant to paragraph (c)(l)(ii) of 37 C.F.R. §41.37. 
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